[issue12936] armv5tejl: random segfaults in getaddrinfo()
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 tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
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 () from /lib/ld-linux.so.2 #1 0x40035a14 in __h_errno_location () from /lib/libpthread.so.0 #2 0x40a788dc in __libc_res_nsearch () from /lib/libresolv.so.2 #3 0x40a66e9c in _nss_dns_gethostbyname3_r () from /lib/libnss_dns.so.2 #4 0x40a670ac in _nss_dns_gethostbyname2_r () from /lib/libnss_dns.so.2 #5 0x40180480 in gaih_inet () from /lib/libc.so.6 #6 0x40181da8 in getaddrinfo () from /lib/libc.so.6 #7 0x406084a4 in socket_getaddrinfo (self=0x405d7bcc, args=0x4089a8b4, kwargs=0x0) at /home/user/mercurial-1.9.2/cpython/Modules/socketmodule.c:4787 #8 0x001ea384 in PyCFunction_Call (func=0x405da1f4, arg=0x4089a8b4, kw=0x0) at Objects/methodobject.c:84 #9 0x000a3634 in call_function (pp_stack=0xbeab7d1c, oparg=4) at Python/ceval.c:4000 #10 0x0009cab8 in PyEval_EvalFrameEx (f=0x407457b4, throwflag=0) at Python/ceval.c:2625 #11 0x000a0bfc in PyEval_EvalCodeEx (_co=0x405d6ab8, globals=0x40591a34, locals=0x0, args=0x408884dc, argcount=2, kws=0x408884e4, kwcount=0, defs=0x40512a20, defcount=2, kwdefs=0x0, closure=0x0) at Python/ceval.c:3375 #12 0x000a3cfc in fast_function (func=0x405e30e4, pp_stack=0xbeab8068, n=2, na=2, nk=0) at Python/ceval.c:4098 #13 0x000a3838 in call_function (pp_stack=0xbeab8068, oparg=2) ---Type return to continue, or q return to quit--- at Python/ceval.c:4021 #14 0x0009cab8 in PyEval_EvalFrameEx (f=0x40888374, throwflag=0) at Python/ceval.c:2625 #15 0x000a0bfc in PyEval_EvalCodeEx (_co=0x4089d5d8, globals=0x4088d854, locals=0x0, args=0x404e2ac8, argcount=2, kws=0x405b43c8, kwcount=2, defs=0x4098fbd0, defcount=6, kwdefs=0x0, closure=0x0) at Python/ceval.c:3375 #16 0x001c3060 in function_call (func=0x40a2dea4, arg=0x404e2ab4, kw=0x409a98f4) at Objects/funcobject.c:629 #17 0x0017f1a0 in PyObject_Call (func=0x40a2dea4, arg=0x404e2ab4, kw=0x409a98f4) at Objects/abstract.c:2149 #18 0x001a1a9c in method_call (func=0x40a2dea4, arg=0x404e2ab4, kw=0x409a98f4) at Objects/classobject.c:318 #19 0x0017f1a0 in PyObject_Call (func=0x4050b9d4, arg=0x404e2574, kw=0x409a98f4) at Objects/abstract.c:2149 #20 0x0004a6c0 in slot_tp_init (self=0x405ae504, args=0x404e2574, kwds=0x409a98f4) at Objects/typeobject.c:5431 #21 0x00037650 in type_call (type=0x40a31034, args=0x404e2574, kwds=0x409a98f4) at Objects/typeobject.c:691 #22 0x0017f1a0 in PyObject_Call (func=0x40a31034, arg=0x404e2574, kw=0x409a98f4) at Objects/abstract.c:2149 #23 0x000a46bc in do_call (func=0x40a31034, pp_stack=0xbeab84f0, na=1, nk=2) at Python/ceval.c:4220 #24 0x000a3858 in call_function (pp_stack=0xbeab84f0, oparg=513) at Python/ceval.c:4023 #25 0x0009cab8 in PyEval_EvalFrameEx (f=0x40558544, throwflag=0) at Python/ceval.c:2625 #26 0x000a0bfc in PyEval_EvalCodeEx (_co=0x40479d28, globals=0x403d5034, locals=0x403d5034, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3375 #27 0x000916f4 in PyEval_EvalCode (co=0x40479d28, globals=0x403d5034, locals=0x403d5034) at Python/ceval.c:770 #28 0x000e0cb4 in run_mod (mod=0x37c8f8, filename=0x405028c8 crash.py, globals=0x403d5034, locals=0x403d5034, flags=0xbeab8864, arena=0x2e5178) at Python/pythonrun.c:1793 #29 0x000e0a58 in PyRun_FileExFlags (fp=0x2ce260, filename=0x405028c8 crash.py, start=257, globals=0x403d5034, locals=0x403d5034, closeit=1, flags=0xbeab8864) at Python/pythonrun.c:1750 #30 0x000debcc in PyRun_SimpleFileExFlags (fp=0x2ce260, filename=0x405028c8 crash.py, closeit=1, flags=0xbeab8864) at Python/pythonrun.c:1275 #31 0x000dde68 in PyRun_AnyFileExFlags (fp=0x2ce260, filename=0x405028c8 crash.py, closeit=1, flags=0xbeab8864) at Python/pythonrun.c:1046 #32 0x000ff984 in run_file (fp=0x2ce260, filename=0x401fe028, p_cf=0xbeab8864) at Modules/main.c:299 #33 0x00100780 in Py_Main (argc=2, argv=0x401fc028) at Modules/main.c:693 #34 0x0001a914 in main (argc=2, argv=0xbeab8994) at ./Modules/python.c:59 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
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 http://sources.redhat.com/bugzilla/show_bug.cgi?id=12453 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
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 case that only crashes on debian-arm when sched_setaffinity() is called *and* the program is linked to pthread: $ gcc -Wall -W -O0 -g -o crash crash.c $ ./crash $ $ gcc -Wall -W -O0 -g -o crash crash.c -pthread $ ./crash Segmentation fault (core dumped) # comment out: sched_setaffinity(0, size, cpusetp); $ gcc -Wall -W -O0 -g -o crash crash.c -pthread $ ./crash $ On Ubuntu all three cases run fine. Perhaps this is a bug in sched_setaffinity()? -- Added file: http://bugs.python.org/file23143/crash.c ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
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 an interleaved way, the TLS can be returned uninitialized, hence the segfault upon access. This problem can show up now because the import orders for some modules have been modified: depending on the test that crashes - or rather the tests that run just before - you might be able to pinpoint it quickly (or you could maybe use ltrace -e dlopen). Apparently, Etch on ARM uses linuxthread instead of NPTL ... FYI you can also try to print sys.thread_info (which should give the same information, NPTL 2.7). NPTL has know issues: see for example the Python issue #4970. NPTL is old and has been replaced by pthread in the glibc on Linux. I think you're confusing with linuxthreads ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
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 tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
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, I also did a run using e91ad9669c08 but without compiling and linking faulthandler, so that _PyFaulthandler_Init() wouldn't be called. This had the same result, so faulthandler is _not_ the cause of this bug. Version 9d658f000419, which is pre-faulthandler, runs without segfaults. If it's a regression, you must try hg bisect! It is slow but it is fully automated! Try something like: hg bisect -r hg bisect -b 9d658f000419 hg bisect -c 'make ./python -m test test_urllib2_localnet test_robotparser test_nntplib' If it were that easy! I can't isolate the bug. The only way I can reproduce it is by running the whole test suite with various random seeds. Then it takes about 6 hours until the crash occurs in one of those tests. The whole test suite takes about 24 hours. I could try to install libc-dbg though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
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 /lib/ld-linux.so.2 (gdb) bt #0 0x40011d20 in __tls_get_addr () from /lib/ld-linux.so.2 #1 0x40011d10 in __tls_get_addr () from /lib/ld-linux.so.2 Backtrace stopped: frame did not save the PC -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
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 with `with-pydebug`? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
Changes by Meador Inge mead...@gmail.com: -- nosy: +meadori ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
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 -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
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 GNU_LIBPTHREAD_VERSION return on your box? 2) If it's using linxthreads, the culprit is likely the call to PyGILState_GetThisThreadState() from faulthandler_fatal_error(), which does a TLS lookup (which screws up because it's running in a user-allocated stack allocated with sigaltstack). However, this should only happen when a a fatal signal is handled by faulthandler, which should - AFAICT - only happen in test_faulthandler. Rebuilding faulthandler with #undef HAVE_SIGALTSTACK at the top of the file, should do the trick. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
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 revision, but there are several glibc issues with __tls_get_addr(): 1) http://www.cygwin.com/ml/libc-hacker/2008-10/msg5.html 2) http://sources.redhat.com/bugzilla/show_bug.cgi?id=12453 If I run the demo script from 2), I get a segfault both on debian-arm as well as on Ubuntu Lucid. So, it may very well be that some recent change in Python exposes a glibc problem. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
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 this issue is a duplicate of glibc bug 12453. Could faulthandler cause problems ... faulthandler creates two locks at startup. faulthandler.enable() (e.g. called by regrtest when running the the test suite) creates a thread and changes the signal mask of this thread (to ignore all signals). I don't see how faulthandler can be linked to this issue, but yes, it might be the linked to this issue. In your case, faulthandler only reads a TLS on a crash. So faulthandler is not the cause of the initial crash, but it may cause a new fault :-) -- Apparently, Etch on ARM uses linuxthread instead of NPTL ... FYI you can also try to print sys.thread_info (which should give the same information, NPTL 2.7). NPTL has know issues: see for example the Python issue #4970. NPTL is old and has been replaced by pthread in the glibc on Linux. -- Traceback with faulthandler disabled: ... How did you disabled faulthandler? -- Version 9d658f000419, which is pre-faulthandler, runs without segfaults. If it's a regression, you must try hg bisect! It is slow but it is fully automated! Try something like: hg bisect -r hg bisect -b 9d658f000419 hg bisect -c 'make ./python -m test test_urllib2_localnet test_robotparser test_nntplib' -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
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 rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
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 suggest we close this. What do you think? gdb ./python ./build/test_python_2217/core Core was generated by `./python -m test -uall -r --randseed=8304772'. Program terminated with signal 11, Segmentation fault. [New process 2217] #0 0x400356f4 in raise () from /lib/libpthread.so.0 (gdb) bt #0 0x400356f4 in raise () from /lib/libpthread.so.0 #1 0x400356d8 in raise () from /lib/libpthread.so.0 Backtrace stopped: frame did not save the PC (gdb) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
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 create_connection File /home/user/cpython-e91ad9669c08/Lib/http/client.py, line 721 in connect File /home/user/cpython-e91ad9669c08/Lib/http/client.py, line 743 in send File /home/user/cpython-e91ad9669c08/Lib/http/client.py, line 805 in _send_output File /home/user/cpython-e91ad9669c08/Lib/http/client.py, line 960 in endheaders File /home/user/cpython-e91ad9669c08/Lib/http/client.py, line 1002 in _send_request File /home/user/cpython-e91ad9669c08/Lib/http/client.py, line 964 in request File /home/user/cpython-e91ad9669c08/Lib/urllib/request.py, line 1145 in do_open File /home/user/cpython-e91ad9669c08/Lib/urllib/request.py, line 1165 in http_open File /home/user/cpython-e91ad9669c08/Lib/urllib/request.py, line 347 in _call_chain File /home/user/cpython-e91ad9669c08/Lib/urllib/request.py, line 387 in _open File /home/user/cpython-e91ad9669c08/Lib/urllib/request.py, line 369 in open File /home/user/cpython-e91ad9669c08/Lib/urllib/request.py, line 138 in urlopen File /home/user/cpython-e91ad9669c08/Lib/unittest/case.py, line 136 in handle File /home/user/cpython-e91ad9669c08/Lib/unittest/case.py, line 572 in assertRaises File /home/user/cpython-e91ad9669c08/Lib/test/test_urllib2_localnet.py, line 537 in test_bad_address File /home/user/cpython-e91ad9669c08/Lib/unittest/case.py, line 386 in _executeTestPart File /home/user/cpython-e91ad9669c08/Lib/unittest/case.py, line 441 in run File /home/user/cpython-e91ad9669c08/Lib/unittest/case.py, line 493 in __call__ File /home/user/cpython-e91ad9669c08/Lib/unittest/suite.py, line 105 in run File /home/user/cpython-e91ad9669c08/Lib/unittest/suite.py, line 67 in __call__ File /home/user/cpython-e91ad9669c08/Lib/unittest/suite.py, line 105 in run File /home/user/cpython-e91ad9669c08/Lib/unittest/suite.py, line 67 in __call__ File /home/user/cpython-e91ad9669c08/Lib/unittest/runner.py, line 168 in run File /home/user/cpython-e91ad9669c08/Lib/test/support.py, line 1293 in _run_suite File /home/user/cpython-e91ad9669c08/Lib/test/support.py, line 1327 in run_unittest File /home/user/cpython-e91ad9669c08/Lib/test/test_urllib2_localnet.py, line 561 in test_main File /home/user/cpython-e91ad9669c08/Lib/test/support.py, line 1420 in decorator File /home/user/cpython-e91ad9669c08/Lib/test/regrtest.py, line 1140 in runtest_inner File /home/user/cpython-e91ad9669c08/Lib/test/regrtest.py, line 905 in runtest File /home/user/cpython-e91ad9669c08/Lib/test/regrtest.py, line 708 in main File /home/user/cpython-e91ad9669c08/Lib/test/__main__.py, line 13 in module File /home/user/cpython-e91ad9669c08/Lib/runpy.py, line 73 in _run_code File /home/user/cpython-e91ad9669c08/Lib/runpy.py, line 160 in _run_module_as_main make: *** [buildbottest] Segmentation fault (core dumped) user@debian-arm:~/cpython-e91ad9669c08$ ulimit -c unlimited user@debian-arm:~/cpython-e91ad9669c08$ ls core ls: cannot access core: No such file or directory user@debian-arm:~/cpython-e91ad9669c08$ find . -name core user@debian-arm:~/cpython-e91ad9669c08$ When I run under gcc, the test are automatically interrupted by SIGINT at some point. Perhaps this is another broken threading implementation. I'll try --without-threads. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12936] armv5tejl: random segfaults in getaddrinfo()
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 running the tests separately. qemu-debian-arm is horrendously slow, so I don't think I'll have time to debug this. I'm submitting the report in case someone has access to fast ARM hardware. [ 81/359/3] test_nntplib Fatal Python error: Segmentation fault Current thread 0x400225f0: File /home/user/cpython-e91ad9669c08/Lib/socket.py, line 389 in create_connection File /home/user/cpython-e91ad9669c08/Lib/nntplib.py, line 1024 in __init__ File /home/user/cpython-e91ad9669c08/Lib/test/test_nntplib.py, line 291 in setUpClass File /home/user/cpython-e91ad9669c08/Lib/unittest/suite.py, line 143 in _handleClassSetUp File /home/user/cpython-e91ad9669c08/Lib/unittest/suite.py, line 97 in run File /home/user/cpython-e91ad9669c08/Lib/unittest/suite.py, line 67 in __call__ File /home/user/cpython-e91ad9669c08/Lib/unittest/suite.py, line 105 in run File /home/user/cpython-e91ad9669c08/Lib/unittest/suite.py, line 67 in __call__ File /home/user/cpython-e91ad9669c08/Lib/unittest/runner.py, line 168 in run File /home/user/cpython-e91ad9669c08/Lib/test/support.py, line 1293 in _run_suite File /home/user/cpython-e91ad9669c08/Lib/test/support.py, line 1327 in run_unittest File /home/user/cpython-e91ad9669c08/Lib/test/test_nntplib.py, line 1260 in test_main File /home/user/cpython-e91ad9669c08/Lib/test/regrtest.py, line 1140 in runtest_inner File /home/user/cpython-e91ad9669c08/Lib/test/regrtest.py, line 905 in runtest File /home/user/cpython-e91ad9669c08/Lib/test/regrtest.py, line 708 in main File /home/user/cpython-e91ad9669c08/Lib/test/__main__.py, line 13 in module File /home/user/cpython-e91ad9669c08/Lib/runpy.py, line 73 in _run_code File /home/user/cpython-e91ad9669c08/Lib/runpy.py, line 160 in _run_module_as_main Segmentation fault -- components: Extension Modules messages: 143723 nosy: skrah priority: normal severity: normal stage: test needed status: open title: armv5tejl: random segfaults in getaddrinfo() type: crash versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
