Stefan Krah stefan-use...@bytereef.org added the comment:
The failure was introduced by issue #12655. I attach a minimal script
to reproduce the segfault.
--
nosy: +benjamin.peterson
Added file: http://bugs.python.org/file23138/crash.py
___
Python
Stefan Krah stefan-use...@bytereef.org added the comment:
And here's a full backtrace of crash.py:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x400225f0 (LWP 633)]
0x40011d20 in __tls_get_addr () from /lib/ld-linux.so.2
(gdb) bt
#0 0x40011d20 in __tls_get_addr
STINNER Victor victor.stin...@haypocalc.com added the comment:
The failure was introduced by issue #12655
Wow, great job!
crash.py looks like a libc and/or kernel bug. Can you try the glibc 2.14
(released the 2011-05-31)? You should first check if it is not a duplicate of
Stefan Krah stefan-use...@bytereef.org added the comment:
I wonder whether it is http://sources.redhat.com/bugzilla/show_bug.cgi?id=12453.
The demo script from there crashes both on debian-arm and Ubuntu Lucid,
but this specific segfault only occurs on debian arm.
Attached is a minimal C test
Charles-François Natali neolo...@free.fr added the comment:
2) http://sources.redhat.com/bugzilla/show_bug.cgi?id=12453
We actually had another issue due to this particular libc bug:
http://bugs.python.org/issue6059
Basically, the problem is that if some libraries are dynamically
loaded in
Charles-François Natali neolo...@free.fr added the comment:
Oh, and BTW, for the Backtrace stopped: frame did not save the PC, you might
want to install the libc-dbg package. This might help in finding precisely
where it's crashing.
--
___
Python
Stefan Krah stefan-use...@bytereef.org added the comment:
STINNER Victor rep...@bugs.python.org wrote:
Traceback with faulthandler disabled: ...
How did you disabled faulthandler?
That was a run with all faulthandler references removed from regrtest.py.
But as I said in my previous mail,
Stefan Krah stefan-use...@bytereef.org added the comment:
Traceback with faulthandler disabled:
Core was generated by `./python -m test -uall -r --randseed=8304772'.
Program terminated with signal 11, Segmentation fault.
[New process 3948]
#0 0x40011d20 in __tls_get_addr () from
Charles-François Natali neolo...@free.fr added the comment:
Traceback with faulthandler disabled:
It crashes when trying to look up TLS (which explains why it doesn't crash when
built ``without-threads`).
Looks like a libc bug, but would it be possible to have a backtrace with Python
built
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meadori
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12936
___
___
Python-bugs-list mailing
Stefan Krah stefan-use...@bytereef.org added the comment:
Curiously enough python *is* built --with-pydebug.
Version 9d658f000419, which is pre-faulthandler, runs without segfaults.
Could faulthandler cause problems like these:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370060
Charles-François Natali neolo...@free.fr added the comment:
Could faulthandler cause problems like these:
Well, that would explain why it crashes in the TLS lookup code, and why the
core dump looks borked.
1) Apparently, Etch on ARM uses linuxthread instead of NPTL: what does
$ getconf
Stefan Krah stefan-use...@bytereef.org added the comment:
I completely removed faulthandler from e91ad9669c08 and the problem
still occurs (with the same broken backtrace).
$ getconf GNU_LIBPTHREAD_VERSION
NPTL 2.7
It is a bit unsatisfying that the segfault isn't reproducible with
the earlier
STINNER Victor victor.stin...@haypocalc.com added the comment:
Looks like a libc bug ...
http://sources.redhat.com/bugzilla/show_bug.cgi?id=12453
Yes, the GNU libc has bugs (as every software!): this one has been fixed only
recently (in glibc 2.14, released the 2011-05-31). I don't know if
Charles-François Natali neolo...@free.fr added the comment:
No such luck. Somehow gdb doesn't dump the core file:
What do
$ /sbin/sysctl -a | grep kernel.core
And
$ grep core /etc/security/limits.conf
return?
--
___
Python tracker
Stefan Krah stefan-use...@bytereef.org added the comment:
This is slightly embarrassing: The partition containing the qemu images
was full. I don't encounter this often, so it tends to be the last thing
I think of.
Proudly presenting a core dump. Since the segfault occurs in
libpthread, I
Charles-François Natali neolo...@free.fr added the comment:
You don't have a core dump, do you?
--
nosy: +neologix
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12936
___
Stefan Krah stefan-use...@bytereef.org added the comment:
No such luck. Somehow gdb doesn't dump the core file:
[ 25/359] test_urllib2_localnet
Fatal Python error: Segmentation fault
Current thread 0x400225f0:
File /home/user/cpython-e91ad9669c08/Lib/socket.py, line 389 in
New submission from Stefan Krah stefan-use...@bytereef.org:
I'm getting random segfaults in `make buildbottest` on qemu-debian-arm:
Linux-2.6.26-2-versatile-armv5tejl-with-debian-5.0.8 little-endian
The segfaults occurred in test_robotparser and test_nntplib and
couldn't be reproduced when
19 matches
Mail list logo
