python 2.5.3 segmentation fault with gcc 4.1.2
hi all, i'm trying to build python 2.5.3 on centos5.2 x86_64 (base gcc is 4.1.2) output of env, configure, make -j and make test at http://users.ugent.be/~stdweird/python-gcc-seg.tar.gz this all seems ok (at least to me ;) but the following code gives a segfault instead of an IOerror fname='test123' f=open(fname,'w') f.read() (test123 doesn't exists. it is a reduced problem from a scipy unittest). with system python (2.4.3) i get: IOError: [Errno 9] Bad file descriptor any hints what might cause this (or how i can figure it out). i have a coredump, but have no clue what to look for. many thanks, stijn -- The system will shutdown in 5 minutes.
Stijn> any hints what might cause this (or how i can figure it out). i Stijn> have a coredump, but have no clue what to look for. I can reproduce it on my Mac. The croak happens while it is attempting to raise the exception about a bad file descriptor. Unfortunately, in PyErr_Restore the call to PyThreadState_GET() returns NULL which means that _PyThreadState_Current is NULL. I see no differences between pystate.[ch] in the 2.5 and 2.6 branches. There must be something different about the way PyThreadState_Swap or PyThreadState_DeleteCurrent are used. Those are the only two routines which appear to set it. Did this not happen with 2.5.2? -- Skip Montanaro - skip@pobox.com - http://smontanaro.dyndns.org/
skip@pobox.com schrieb:
Stijn> any hints what might cause this (or how i can figure it out). i Stijn> have a coredump, but have no clue what to look for.
I can reproduce it on my Mac. The croak happens while it is attempting to raise the exception about a bad file descriptor. Unfortunately, in PyErr_Restore the call to PyThreadState_GET() returns NULL which means that _PyThreadState_Current is NULL. I see no differences between pystate.[ch] in the 2.5 and 2.6 branches. There must be something different about the way PyThreadState_Swap or PyThreadState_DeleteCurrent are used. Those are the only two routines which appear to set it.
Did this not happen with 2.5.2?
Wild guess: the bug might be related to http://bugs.python.org/issue1683. From the top of my head it's the only major change in the thread state code that I can recall. Christian
Stijn De Weirdt wrote:
but the following code gives a segfault instead of an IOerror fname='test123' f=open(fname,'w') f.read()
I've tracked this down to r67740: """ Issue #1706039: Support continued reading from a file even after EOF was hit. """ Looking at the diff, I question the correctness of this patch. I believe the actual issue is the Py_UniversalNewlineFread() was changed to make calls to PyErr_SetFromErrno(), but then these calls occur within an ALLOW_THREADS block. I was going to try to make a new patch, but the test case that was added for it succeeded *before* the patch was applied (I reverted fileobject.c to r67739) on many platforms. I don't have access to a platform which exhibits the problem described in the tracker. Reading people's assessment, I *think* the correct patch is merely to add a call to clearerr() just before calling fread() in each function (to clear the EOF flag before performing the fread()). I don't really understand what the point of all the other changes are in the diff. I can't test my assessment because it seems the only platform discussed that had a problem was OS X (and I don't have one of those). -Scott -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu
participants (4)
-
Christian Heimes -
Scott Dial -
skip＠pobox.com -
Stijn De Weirdt