> 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 Modules/posixmodule.c).

Upon execve, signals handler are reset to default. So maybe the error makes the linuxthread API screw up latter when it tries to set up handlers for SIGRTMIN and friend. But what's weird is that when the executable given does not exist, the call should fail and return before having done anything...

> There's still the question of what changed between 2.x and 3.x:  on 2.x, this buildbot seems perfectly happy.

I think it's simply because we didn't test a wrong program path with execve in 2.X version of test_os.