[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Stefan Krah added the comment: This type of failure appears again in current builds: http://www.python.org/dev/buildbot/builders/x86 gentoo 3.x/builds/2160/steps/test/logs/stdio -- nosy: +skrah versions: +Python 3.2, Python 3.3 ___ Python tracker

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: > This type of failure appears again in current builds: Unfortunately, I think you mean 'still' rather than 'again'. :) As far as I can tell, the failure's never gone away, though it may have been obscured by other failures from time to time. Maybe it's time

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: Should also modify regrtest to print out the result of the command getconf GNU_LIBPTHREAD_VERSION that Antoine suggested. -- ___ Python tracker __

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Stefan Krah added the comment: This bugreport http://bugs.gentoo.org/28193 indeed suggests that the failure occurs on systems without nptl. Would it be possible for someone with an affected system to run the test program from the bug report? -- ___

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Charles-Francois Natali added the comment: Signal 32 is the first real-time signal, and is indeed used by linuxthreads, so it's very likely a linuxthreads bug, since this signal shouldn't leak to application. Since linuxthreads is no longer maintained, I'm afraid we can't do much about this,

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: > Since linuxthreads is no longer maintained, I'm afraid we can't do much > about this. Agreed. But I think it's still worth trying to narrow down (and possibly work around) the cause of failure, just so that we can make this buildbot useful again on 3.x. P

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

STINNER Victor added the comment: Extract of the Prelude ticket https://dev.prelude-ids.com/issues/show/133 : "commenting out sigprocmask(SIG_SETMASK, &set, NULL) seems to fixes the problem (...)" -- nosy: +haypo ___ Python tracker

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: Results of my simple-minded strategy (see r80033-4, r80037, r80042, r80045, r80047-51): test_execvpe_with_bad_program in ExecTests by itself is enough to trigger the signal 32 error (in combination with test_wait3). See: http://www.python.org/dev/buildbot/b

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: Here's some fairly minimal Python code that produces the signal: ### begin example ### import os import time import _thread try: os.execv('/usr/bin/dorothyq', ['dorothyq']) except OSError: pass def f(): time.sleep(1.0) # probably irrelevant to th

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: Okay, I think I've got as far as I can, but if anyone else wants to hack on this, please do. The branch name is py3k-issue4970 In that branch: - there's an extra test Lib/test/test_issue4970 that demonstrates the signal 32 failure - Lib/test/regrtest.p

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

STINNER Victor added the comment: signal.__dict__: {... 'NSIG': 65, 'SIGABRT': 6, 'SIGALRM': 14, 'SIGBUS': 7, 'SIGCHLD': 17, 'SIGCLD': 17, 'SIGCONT': 18, 'SIGFPE': 8, 'SIGHUP': 1, 'SIGILL': 4, 'SIGINT': 2, 'SIGIO': 29, 'SIGIOT': 6, 'SIGKILL': 9, 'SIGPIPE': 13, 'SIGPOLL': 29, 'SI

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

STINNER Victor added the comment: There are many references to "unknown signal 32" errors in Google. Gdb mailing list, December 2002: "SIG32/SIGTRAP issues" http://sources.redhat.com/ml/gdb/2002-12/msg00057.html Gdb mailing list, September 2003: "pthread_create, Program received signal ?, Unk

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

STINNER Victor added the comment: NPTL was introduced in Linux kernel 2.6(.0). glibc 2.4 requires NPTL: "The LinuxThreads add-on, providing pthreads on Linux 2.4 kernels, is no longer supported. The new NPTL implementation requires Linux 2.6 kernels. For a libc and libpthread that works well

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Antoine Pitrou added the comment: I suggest simply skipping the "offending" test on linuxthread platforms. (perhaps as simple as checking for sys.platform == "linux2" and signal.SIGRTMIN == 35) -- ___ Python tracker

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

STINNER Victor added the comment: > I suggest simply skipping the "offending" test on linuxthread > platforms. Good idea > (perhaps as simple as checking for sys.platform == "linux2" > and signal.SIGRTMIN == 35) I would prefer to rely on confstr(): import os try: # 'linuxthreads-0.10' o

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: Skipping test_execvpe_with_bad_program sounds good to me. I'd ideally like to understand why 3.x is failing where 2.x is happy, but life's too short to stuff a mushroom. -- ___ Python tracker

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Charles-Francois Natali added the comment: > It looks as though the failed os.execv call messes something up internally, > so that any attempt thereafter to start a thread produces this signal. I > can't see anything obviously wrong with the os.execv implementation (see > posix_execv in Modu

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

STINNER Victor added the comment: > I think it's simply because we didn't test a wrong program path > with execve in 2.X version of test_os. Oh, we should add this test to Python2 ;-) -- ___ Python tracker __

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: > I think it's simply because we didn't test a wrong program path with execve > in 2.X version of test_os. D'oh! Thank you very much. I'm happy now: my mushroom's stuffed. :) -- ___ Python tracker

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Neal Norwitz added the comment: Thanks for taking care of this guys. Sorry, I got swamped with mail and had to archive 3,000+ messages. It looks like it's in good hands. Let me know if there's anything you need. I may not have access to the box anymore, however, I can always contact Kurt. -

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: Victor, that patch looks fine to me. Do you want to go ahead and apply it, and add the skip to test_execvpe_with_bad_program ? The fix should be backported to 3.1, but not to 2.x (I think), since we don't have a problem there, and arguably the new os.confstr

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: And just for reference, http://www.python.org/dev/buildbot/builders/x86%20gentoo%203.x/builds/2192 shows that the relevant versions on this machine are: glibc 2.3.4 linuxthreads-0.10 and from http://www.python.org/dev/buildbot/builders/x86%20gentoo%203.x, i

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

STINNER Victor added the comment: Commited as r80108 to py3k: "Add CS_GNU_LIBC_VERSION and CS_GNU_LIBPTHREAD_VERSION constants for constr(), and disable test_execvpe_with_bad_program() of test_os if the libc uses linuxthreads to avoid the "unknown signal 32" bug (see issue #4970)." Wait for

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: Fix merged to release31-maint in r80119. Thanks, Victor. -- components: +Tests resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> crash ___ Python tracker

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Changes by R. David Murray : -- nosy: +r.david.murray ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: It would also be interesting to know whether Neal's system is using the LinuxThreads library, or whether it's using NPTL. If it's the former, it might go some way to explaining the problem. -- ___ Python tracker

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

R. David Murray added the comment: I was unable to reproduce this using the suggested regrtest pair, even if I ran -R ::, on Gentoo, kernel 2.6.30, with nptl. -- priority: -> normal ___ Python tracker

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Sridhar Ratnakumar added the comment: [...] test_poll test_popen test_poplib stub-asunix.sh: line 238: 25474 Unknown signal 32 $PYTHON $installdir/lib/python?.?/test/regrtest.py -w -u all,-curses,-audio,- network -x $SKIPS stub: core Python test suite FAILED (retval: 160) -- nosy

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: srid, I'm not sure why you added your comment; a couple of sentences explaining where the output you posted comes from (what machine, what version of Python, under what circumstances) would be really useful. If you're able to reproduce this failure and have

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Sridhar Ratnakumar added the comment: Sorry about the late response; have been busy of late. I believe this error ("Unknown signal 32") appears consistently in 3.0.1, 3.1rc1, 3.1 and 3.1.1. It appears only on Linux x86. (64-bit has failures of different kind..) I am attaching the entire log

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Sridhar Ratnakumar added the comment: .. and here are the machine details: a...@gila:~> uname -a Linux gila 2.4.21-297-default #1 Sat Jul 23 07:47:39 UTC 2005 i686 i686 i386 GNU/Linux a...@gila:~> cat /etc/*release LSB_VERSION="1.3" DISTRIB_ID="SuSE" DISTRIB_RELEASE="9.0" DISTRIB_DESCRIPTION="

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Sridhar Ratnakumar added the comment: libc used is of version 2.3.2. *** a...@gila:~> ldd rrun/tmp/autotest/ActivePython-3.1.1.2-linux-x86/ INSTALLDIR/bin/python3 libpthread.so.0 => /lib/i686/libpthread.so.0 (0x4002f000) libdl.so.2 => /lib/libdl.so.2 (0x4008) libuti

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Antoine Pitrou added the comment: Prelude has had the same problem with signal 32: https://dev.prelude-ids.com/issues/show/133 According to their research, it is due to the linuxthreads implementation of the pthread API. To know which threads implementation your glibc is using, you can run "get

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Antoine Pitrou added the comment: Sridhar, Neal, I would advocate disabling (commenting out) test_closerange in Lib/test/test_os.py and see what happens. That's the one really dirty test in test_os, it might close a file handle linuxthreads is relying on. -- __

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Antoine Pitrou added the comment: Forget the last comment, test_closerange is fine... -- ___ Python tracker ___ ___ Python-bugs-list m

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Changes by R. David Murray : -- keywords: +buildbot ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

New submission from Mark Dickinson : The x86 gentoo 3.0 and 3.x buildbots have been failing for a while at the test stage, with: make: *** [buildbottest] Unknown signal 32 program finished with exit code 2 I noticed a common denominator with these failures, which is that they always seem to o

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: Another observation is that after test_os has been run, the first test to actually cause the 'unknown signal' failure always seems to be one that involves threads (e.g., test_wait3, or test_queue, or test_logging...) ___ Py

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: ...and there's a related message from Neal Norwitz at: http://mail.python.org/pipermail/python-3000/2007-August/009944.html I suspect that python Lib/test/regrtest.py test_os test_wait3 (possibly with some additional flags to regrtest.py) should be enough to