Ofcourse it could always be a problem with this dev server, but it's
been in use for a couple of years without any problems. Its a pretty
standard debian woody setup with python2.4.4 and django over apache2.2
and mod_python3.2.10.
On Apr 20, 11:31 am, simonbun <[EMAIL PROTECTED]> wrote:
> 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 django-users@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
