Intermittent error since last svn up
simonbun
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.
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.
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
Malcolm Tredinnick
> 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.
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
simonbun
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 <malc...@pointy-stick.com>
wrote:
simonbun
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.
Malcolm Tredinnick
> 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.
Any chance you can narrow it down a bit more please? You said it wasn't
occurring a week ago -- which was about a week after we already had
delayed_loader() in place. So that makes me think it is something else
causing the problem. You are currently the only person reporting this
problem and I couldn't replicate it when I tried it with my local
mod_python setup just now. So I'd like to find out what really triggered
the problem and try to fix it.
Thanks,
Malcolm
simonbun
causes it. Wich is the first import of the code.
Normally more people would have noticed this problem if it's been
around since 4905, so i'm guessing those changes somehow clash with my
dev server setup...
Any clues as to what my cause it? I've tried deactivation psyco
(grasping at straws here), but no change.
On Apr 20, 11:58 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
Malcolm Tredinnick
> I've "svn up -r #"d through all the revisions and it seems 4905
> causes it. Wich is the first import of the code.
>
> Normally more people would have noticed this problem if it's been
> around since 4905, so i'm guessing those changes somehow clash with my
> dev server setup...
>
> Any clues as to what my cause it? I've tried deactivation psyco
> (grasping at straws here), but no change.
Truly odd. The thing is, traceback.extract_stack() is written in Python
and works exactly as you might expect.
Maybe inside your try/except block, check if you have a
sys.tracebacklimit attribute and, if so, is it zero by any chance? I'm
just wondering if that's something your system is setting. It's not
normally present, but you can set it to control the depth of traceback
information.
Oh .. and one other thought, what does traceback.extract_tb() show
inside the "except" clause after catching the index error? Does it show
a full and useful traceback -- including all the stack frames? I suspect
it will, which will be mystifying, but interesting to know nevertheless.
If I understood what was causing this problem and that we could deem it
truly harmless, I'd be willing to put in a workaround for the specific
case of extract_stack() being empty. However, at the moment, it's too
weird to do that, since I don't understand why it's needed.
Sorry to keep hitting you with questions requiring poking at your dev
server, but this is a real mystery and I feel a bit responsible to try
and fix it (I'd be quite happy if somebody else wanted to feel
responsible and fix it instead, but that's unlikely).
Regards,
Malcolm
simonbun
When I said earlier that I tried disabling psyco, I seem to have made
the silly mistake of disabling it on one project, and testing for the
result on another. Mental note to self: opening more than 1 project at
a time will only confuse your little mind.
Psyco causes the problem, and it's probably limited to my specific
version of psyco (which is 1.5.1 final, for anyone that's interested).
I could go dig deeper to see what causes that, but that will be for
some other day... it's Friday for Pete's sake ;)
Anyway, thanks a lot for your help Malcolm!
On Apr 20, 12:22 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
Malcolm Tredinnick
> Ok I've found the problem...
>
> When I said earlier that I tried disabling psyco, I seem to have made
> the silly mistake of disabling it on one project, and testing for the
> result on another. Mental note to self: opening more than 1 project at
> a time will only confuse your little mind.
>
> Psyco causes the problem, and it's probably limited to my specific
> version of psyco (which is 1.5.1 final, for anyone that's interested).
> I could go dig deeper to see what causes that, but that will be for
> some other day... it's Friday for Pete's sake ;)
Oh. Psyco. :-(
Okay, that actually makes a little bit of sense. Stack frame
introspection in psyco is a bit hard to do properly. I hadn't thought of
that when I wrote the code in question. Still, it might be possible to
work around this... I'll need to experiment a bit, but you've given me
something to work with.
Regards,
Malcolm