[issue12936] armv5tejl: random segfaults in getaddrinfo()

[STINNER Victor]

STINNER Victor <victor.stinner at 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 <report at bugs.python.org>
<http://bugs.python.org/issue12936>
_______________________________________