On Tue, Dec 30, 2014 at 5:58 AM, Peter Otten <__pete...@web.de> wrote:
> OK. sre_constants.py looks pretty generic, the only module it imports (_sre)
> is a built-in and the interpreter is known-good. If the modules imported
> before sre_constants.py are known-good, too, and no other debian user sees
> the same problem I'm out of realistic ideas.
I'm looking at the source for it, and it *mentions* _sre, but doesn't
seem to actually import it. sre_compile.py has already imported it,
apparently successfully, before sre_constants loads up.
Ah! The issue doesn't seem to be sre_constants per se; I can import
that just fine. In fact, "import re" segfaults *after* importing
sre_constants. If I take a copy of a file into the current directory
and run "python -Sc 'import re'", it uses my copy of the file (though
just "python" doesn't, which probably means dot isn't added to
sys.path soon enough?); and by using a tweaked version of one file or
other, I've managed to narrow down the problem. And simply copying
sre_parse.py locally prevents the segfault, even without edits!
By inserting "raise Exception" at the point where I think the problem
is, I get this traceback, which approximates to the call depth I've
dug into so far:
$ python -Sc 'import re'
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python2.7/re.py", line 222, in <module>
_pattern_type = type(sre_compile.compile("", 0))
File "/usr/lib/python2.7/sre_compile.py", line 500, in compile
p = sre_parse.parse(p, flags)
File "sre_parse.py", line 665, in parse
raise Exception
Exception
Unlike playing with sre_constants.pyc, this one *does* result in a
different file after renaming away the .pyc. So somehow, SOMEHOW, the
.pyc file became corrupt. Is this something worth reporting? I now
have what appears to be a file whose presence in the current directory
can crash Python.
Thanks for the help, all! At least now I have a working system again.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
