[issue12936] armv5tejl: random segfaults in getaddrinfo()

Stefan Krah 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 case that only crashes on d

[issue12936] armv5tejl: random segfaults in getaddrinfo()

STINNER Victor 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 http://sources.redhat.com/bugzilla/show_bug.cg

[issue12936] armv5tejl: random segfaults in getaddrinfo()

Stefan Krah 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 () from /lib/ld-linux.so.2 #

[issue12936] armv5tejl: random segfaults in getaddrinfo()

Stefan Krah 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 tracker

[issue12936] armv5tejl: random segfaults in getaddrinfo()

Stefan Krah added the comment: STINNER Victor 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, I also did a run using e91ad9669c08 but witho

[issue12936] armv5tejl: random segfaults in getaddrinfo()

Charles-François Natali 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 tracker

[issue12936] armv5tejl: random segfaults in getaddrinfo()

Charles-François Natali 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 an interleaved wa

[issue12936] armv5tejl: random segfaults in getaddrinfo()

STINNER Victor 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 this issue is a duplicate o

[issue12936] armv5tejl: random segfaults in getaddrinfo()

Stefan Krah 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 revision, but there are se

[issue12936] armv5tejl: random segfaults in getaddrinfo()

Charles-François Natali 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 GNU_LIBPTHREAD_VERSIO

[issue12936] armv5tejl: random segfaults in getaddrinfo()

Stefan Krah 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 -- nosy: +haypo

[issue12936] armv5tejl: random segfaults in getaddrinfo()

Changes by Meador Inge : -- nosy: +meadori ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue12936] armv5tejl: random segfaults in getaddrinfo()

Charles-François Natali 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 with `with-pydebu

[issue12936] armv5tejl: random segfaults in getaddrinfo()

Stefan Krah 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 /lib/ld-linux.so.2 (gdb) bt #0 0x40011d2

[issue12936] armv5tejl: random segfaults in getaddrinfo()

Stefan Krah 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 suggest we close this. What do y

[issue12936] armv5tejl: random segfaults in getaddrinfo()

Charles-François Natali 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

[issue12936] armv5tejl: random segfaults in getaddrinfo()

Stefan Krah 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 create_connection File "/home/user/cpyt

[issue12936] armv5tejl: random segfaults in getaddrinfo()

Charles-François Natali added the comment: You don't have a core dump, do you? -- nosy: +neologix ___ Python tracker ___ ___ Python-b

[issue12936] armv5tejl: random segfaults in getaddrinfo()

New submission from Stefan Krah : 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 running the tests separately.