File uploads sometimes incorrectly detect an infinite loop.

[lakin.wecker@…]

just updated my django trunk install and am not getting a ​http://dpaste.com/60810/ that wasn't there before ​http://code.djangoproject.com/changeset/7814 ... now I realize that this presents a backwards incompatible change, but the error is coming from the admin interface (one that does have a file field) but I'm not uploading a file

Will upload the traceback from the paste on this ticket as well.

The models used:

from django.db import models 
from django.conf import settings


#-------------------------------------------------------------------------------
class File(models.Model):
    """
    """
    path = models.CharField(max_length=255, unique=True)

    folder = 'protected_files'
    file = models.FileField(upload_to=folder,)
    number_of_codes_to_create = models.PositiveIntegerField(
        help_text = "Use this to generate new codes on save."
    )
    max_uses_for_created_codes =  models.PositiveIntegerField(
        default=2,
        help_text = "New codes will have this many uses on generation."
    )

    def __unicode__(self) :
        return self.filename()

    class Admin:
        pass



#-------------------------------------------------------------------------------
class FileCode(models.Model):
    """
    """

    file = models.ForeignKey(
        File,
        edit_inline=models.TABULAR,
        related_name='codes'
    )
    code = models.CharField(max_length=10, core=True)

    uses = models.IntegerField(default=0)
    max_uses = models.PositiveIntegerField(default=2)


    class Admin:
        pass

[lakin.wecker@…]

backtrace_from_error.txt

[Malcolm Tredinnick]

@axiak: This looks like your department. Any ideas?

[Michael Axiak]

Hello,

Can you post more information? Specifically, the following would be extremely helpful:

1. What browser were you using?
2. How were you deploying Django (test server, mod_python, mod_wsgi, fastcgi, ...)?

I'm trying to replicate this now.

[lakin.wecker@…]

Firefox 3. It happened with both the dev server and apache/mod_python deployment.

[Michael Axiak]

Okay, after working with lakin online for about an hour I found the issue.

The issue is that in order to prevent us from entering an infinite loop while parsing, we have a counter that essentially counts how many times we enter a segment of code.

We set the limit to something that is "high", like 500. Problem is, this counter gets incremented whenever there is an additional piece of form data.

In your example, you had a file field, so the form encoding was multipart/form-data, and you had 815 form fields because of the edit inline.

I'm working on coming up with a better way to detect an infinite loop. If there is no better place, then could we make the limit something incredibly high? (100000 comes to mind) or remove it altogether?

The reason for it is that in early development we had cases where we struck an infinite loop, and it was a bad failure mode. We figured this error would be better than that failure.

[Michael Axiak]

Increase counter from 500 to 64000.

[Michael Axiak]

Increase counter from 500 to 64000.

[Michael Axiak]

Disregard second_patch.diff :-).

I'm opting for increasing the limit to 64,000 for now. I think we should have some more battle testing before we remove this check outright.

[Malcolm Tredinnick]

(Changed description to something approaching the real problem.)

[Michael Axiak]

I actually use the component...

[Michael Axiak]

I'm uploading an attempt at a different recursion metric that should work much better.

[Michael Axiak]

Different way to check recursion

[Michael Axiak]

Adding keywords...

[Michael Axiak]

I think we can be happy with this fix.

[Jacob]

(In [7905]) Fixed #7635: do a better job checking for infinite loops in multi-part MIME parsing. Thanks, Mike Axiak.

[Jacob]

Milestone 1.0 beta deleted