[Python-Dev] serious bug in new import X as Y code

[Sjoerd Mullender]

Ok, problem solved.

The problem was that because of your (I think it was you :-) earlier
change to have a Makefile in Grammar, I had an old graminit.c lying
around in my build directory.  I don't build in the source directory
and the changes for a Makefile in Grammar resulted in a file
graminit.c in the wrong place.  My subsequent change to this part of
the build process resulted in a different place for graminit.c and I
never removed the bogus graminit.c (because I didn't know about it).
However, the compiler found the bogus one so that's why python
crashed.

On Fri, Aug 18 2000 Thomas Wouters wrote:

> On Fri, Aug 18, 2000 at 11:42:38AM +0200, Sjoerd Mullender wrote:
> 
> > Your changes for the import X as Y feature introduced a serious bug:
> > I can no longer run Python at all.
> 
> > The problem is that in line 2150 of compile.c com_addopname is called
> > with a NULL last argument, and the firat thing com_addopname does is
> > indirect off of that very argument.  On my machine (and on many other
> > machines) that results in a core dump.
> 
> Hm. That's very strange. Line 2150 of compile.c calls com_addopname with
> 'CHILD(CHILD(subn, 0), 0)' as argument. 'subn' is supposed to be a
> 'dotted_as_name', which always has at least one child (a dotted_name), which
> also always has at least one child (a NAME). I don't see how dotted_as_name
> and dotted_name can be valid nodes, but the first child of dotted_name be
> NULL.
> 
> Can you confirm that the tree is otherwise unmodified ? If you have local
> patches, can you try to compile and test a 'clean' tree ? I can't reproduce
> this on the machines I have access to, so if you could find out what
> statement exactly is causing this behaviour, I'd be very grateful. Something
> like this should do the trick, changing:
> 
>                         } else
>                                 com_addopname(c, STORE_NAME,
>                                               CHILD(CHILD(subn, 0),0));
> 
> into
> 
>                         } else {
>                                 if (CHILD(CHILD(subn, 0), 0) == NULL) {
>                                         com_error(c, PyExc_SyntaxError,
>                                                   "NULL name for import");
>                                         return;
>                                 }
>                                 com_addopname(c, STORE_NAME,
>                                               CHILD(CHILD(subn, 0),0));
>                         }
> 
> And then recompile, and remove site.pyc if there is one. (Unlikely, if a
> crash occured while compiling site.py, but possible.) This should raise a
> SyntaxError on or about the appropriate line, at least identifying what the
> problem *could* be ;)
> 
> If that doesn't yield anything obvious, and you have the time for it (and
> want to do it), some 'print' statements in the debugger might help. (I'm
> assuming it works more or less like GDB, in which case 'print n', 'print
> n->n_child[1]', 'print subn', 'print subn->n_child[0]' and 'print
> subn->n_child[1]' would be useful. I'm also assuming there isn't an easier
> way to debug this, like you sending me a corefile, because corefiles
> normally aren't very portable :P If it *is* portable, that'd be great.)
> 
> > In case it helps, here is the stack trace.  The crash happens when
> > importing site.py.  I have not made any changes to my site.py.
> 
> Oh, it's probably worth it to re-make the Grammar (just to be sure) and
> remove Lib/*.pyc. The bytecode magic changes in the patch, so that last
> measure should be unecessary, but who knows :P
> 
> breaky-breaky-ly y'rs,
> -- 
> Thomas Wouters <thomas@xs4all.net>
> 
> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
> 

-- Sjoerd Mullender <sjoerd.mullender@oratrix.com>