I think this is going to weird you out even more. I wrapped it in a
try/except block and the traceback.extract_stack() returns an empty
list...
For the time being I've rolled back to 0.96 and everything works as
expected. Also, the problem occurs in all of my django projects, so
its definitely a problem with trunk, somewhere somehow.
Very weird error indeed, especially because after 2-3 requests the
problem goes away.
On Apr 20, 10:16 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Fri, 2007-04-20 at 07:04 +0000, simonbun wrote:
> > Hi all,
>
> > I'm getting a weird intermittent exception since i updated django from
> > trunk yesterday. When I reload apache and request any page I get an
> > exception for about 3 times, and then after that all goes as intended.
>
> This -- and the information you provide below -- is truly bizarre. I
> wrote the code that is blowing up and I don't understand what is causing
> it, so there are a few requests for more help below...
>
> > It seems to be a problem with the delayed_loader that replaces each
> > real_* i18n function on first call. I can see that part of the code
> > has changed in changeset 4905, but I'm not sure what exactly is
> > causing the problem.
>
> > I'm not sure what revision i was updating from, but it couldn't have
> > been more than a week ago since I last updated.
>
> Can you try back-tracking a little bit to earlier changesets and see if
> the problem goes away? The changes to introduce delayed_loader() are a
> few weeks old now (it was the week before Easter that I put them in), so
> if you really did only see the error due to changes in the past week, it
> would be good to have a more precise point that caused the problem.
>
>
>
> > In any case, here's the stack trace:
>
> > Mod_python error: "PythonHandler django.core.handlers.modpython"
>
> > Traceback (most recent call last):
>
> > File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line
> > 299, in HandlerDispatch
> > result = object(req)
>
> > File "/usr/lib/python2.4/site-packages/django/core/handlers/
> > modpython.py", line 177, in handler
> > return ModPythonHandler()(req)
>
> > File "/usr/lib/python2.4/site-packages/django/core/handlers/
> > modpython.py", line 145, in __call__
> > self.load_middleware()
>
> > File "/usr/lib/python2.4/site-packages/django/core/handlers/
> > base.py", line 29, in load_middleware
> > mod = __import__(mw_module, {}, {}, [''])
>
> > File "/usr/lib/python2.4/site-packages/django/contrib/sessions/
> > middleware.py", line 2, in ?
> > from django.contrib.sessions.models import Session
>
> > File "/usr/lib/python2.4/site-packages/django/contrib/sessions/
> > models.py", line 51, in ?
> > class Session(models.Model):
>
> > File "/usr/lib/python2.4/site-packages/django/db/models/base.py",
> > line 35, in __new__
> > new_class.add_to_class('_meta', Options(attrs.pop('Meta', None)))
>
> > File "/usr/lib/python2.4/site-packages/django/db/models/base.py",
> > line 174, in add_to_class
> > value.contribute_to_class(cls, name)
>
> > File "/usr/lib/python2.4/site-packages/django/db/models/options.py",
> > line 53, in contribute_to_class
> > setattr(self, 'verbose_name_plural',
> > meta_attrs.pop('verbose_name_plural', self.verbose_name + 's'))
>
> > File "/usr/lib/python2.4/site-packages/django/utils/functional.py",
> > line 42, in __wrapper__
> > res = self.__func(*self.__args, **self.__kw)
>
> > File "/usr/lib/python2.4/site-packages/django/utils/translation/
> > __init__.py", line 52, in gettext
> > return real_gettext(message)
>
> > File "/usr/lib/python2.4/site-packages/django/utils/translation/
> > __init__.py", line 34, in delayed_loader
> > caller = traceback.extract_stack(limit=2)[0][2]
>
> > IndexError: list index out of range
>
> Very weird! I'd like to claim there's no possible way this exception can
> be raised. It would only make sense if (a) the entries in the list
> returned by extract_stack() did not have three elements each (which
> would be a Python bug) or (b) the stack contained *zero* frames, which
> is clearly not true, since there's a whole traceback full of stack
> frames there printed out for everybody to see.
>
> Since it clearly is occurring and you seem to be in a position to be
> able to repeat the problem, could you gather some more information
> please?
>
> What I would like to see is what happens when you wrap a try/except
> block around that last statement to catch the error and then print out
> (to a file or to sys.stderr) the results of traceback.extract_stack().
> Then re-raise the exception so that it fails as per normal.
>
> At the moment, I'm stumped. Something's gone mental and extract_stack()
> is very confused. If you can get me the extra information, I might be
> able to think of something else to try.
>
> Regards,
> Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
