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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4