[issue15589] Bus error on Debian sparc

Stefan Krah added the comment: Closing since the remaining issue is almost certainly a platform bug. -- keywords: -3.2regression, patch resolution: -> wont fix stage: needs patch -> committed/rejected status: open -> closed ___ Python tracker

[issue15589] Bus error on Debian sparc

Martin v. Löwis added the comment: I'd like to urge everybody to focus at one issue at a time. This issue is about Python crashing on a SparcLinux qemu image, so I think it should have priority "low" - there is absolutely no requirement that this needs to work. As for the test failures on Sola

[issue15589] Bus error on Debian sparc

Stefan Krah added the comment: > If disabling faulthandler avoids new issues, you can add 'if > [not] sys.thread_info.version.startswith("linuxthreads")' That suppresses some bus errors. However, they still occur without being raised (some print statements and a WIFSIGNALED test inserted in posi

[issue15589] Bus error on Debian sparc

STINNER Victor added the comment: > With all faulthandler references removed from regrtest.py no > bus errors happen, but most tests fail anyway. As I said, I'm > NOT blaming faulthandler, but suspect some strange platform > bug that perhaps involves linuxthreads. Threads + signal is a very comp

[issue15589] Bus error on Debian sparc

Stefan Krah added the comment: > 329 tests OK. > 7 tests failed: > test_cmd_line test_exceptions test_ipaddress test_os test_raise > test_socket test_traceback Thanks. A lot of these appear to be big-endian related, see #15597. -- ___ Python

[issue15589] Bus error on Debian sparc

Floris Bruynooghe added the comment: I can now confirm the whole testsuite runs, so the BusError part seems fixed on my host: 329 tests OK. 7 tests failed: test_cmd_line test_exceptions test_ipaddress test_os test_raise test_socket test_traceback 1 test altered the execution environment

[issue15589] Bus error on Debian sparc

Stefan Krah added the comment: As for the original error: in test_subprocess basically every test fails. With the standard regrtest.py (faulthandler enabled), most tests generate a bus error in subprocess_fork_exec(): 621 cwd_obj2 = NULL; (gdb) 624 pid = fork(); <- bus err

[issue15589] Bus error on Debian sparc

Floris Bruynooghe added the comment: I think I can confirm this fixes the BusError. The test suite got past test_capi on my machine as well. Unfortunately I killed the ssh session by accident before the testsuite completed so I had to restart it. -- _

[issue15589] Bus error on Debian sparc

Roundup Robot added the comment: New changeset efb30bdcfa1e by Larry Hastings in branch 'default': Issue #15589: Ensure double-alignment for brute-force capi argument parser test http://hg.python.org/cpython/rev/efb30bdcfa1e -- nosy: +python-dev ___ P

[issue15589] Bus error on Debian sparc

Stefan Krah added the comment: Larry Hastings wrote: > Attached is a patch attempting to force double alignment. Stefan: please > apply and try it. Does this help? Yes, this works nicely. -- ___ Python tracker

[issue15589] Bus error on Debian sparc

Floris Bruynooghe added the comment: I compiled with a simple "./configure" which I think is what you mean (it defaults to -O3). But when executing your test it doesn't give a bus error. -- ___ Python tracker ___

[issue15589] Bus error on Debian sparc

Larry Hastings added the comment: Attached is a patch attempting to force double alignment. Stefan: please apply and try it. Does this help? -- keywords: +patch Added file: http://bugs.python.org/file26727/larry.force.alignment.in.capi.test.1.diff ___

[issue15589] Bus error on Debian sparc

Stefan Krah added the comment: Floris, the traceback in my first message only occurs in the optimized regular build with -O3. Did you try that, too? -- ___ Python tracker ___ ___

[issue15589] Bus error on Debian sparc

Larry Hastings added the comment: nm, I get it, doubles are 8-bytes and should be 8-byte aligned. Let me stare at it some more. -- ___ Python tracker ___ __

[issue15589] Bus error on Debian sparc

Larry Hastings added the comment: This platform is 8-byte aligned? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue15589] Bus error on Debian sparc

Stefan Krah added the comment: I think I've identified one legit Python bug. This is from a *different* traceback, i.e. the traceback in my first message is still unresolved. A bus error occurs in test_capi, test_skipitem with format 'D': Python/getargs.c:782 Py_complex *p = va_arg(*p

[issue15589] Bus error on Debian sparc

Floris Bruynooghe added the comment: Running on Solaris 10 (T1000, OpenCSW toolchain, gcc 4.6.3) I also get a bus error, with added coredump: $ ./python Lib/test/regrtest.py == CPython 3.3.0b1 (default:67a994d5657d, Aug 8 2012, 21:43:48) [GCC 4.6.3] == Solaris-2.10-sun4v-sparc-32bit big-endi

[issue15589] Bus error on Debian sparc

Ned Deily added the comment: Is it by any chance a --shared build being run from the build directory without having been installed (and without a LD_LIBRARY_PATH and with an older version already installed)? -- nosy: +ned.deily ___ Python tracker <

[issue15589] Bus error on Debian sparc

Georg Brandl added the comment: >From the position of the bus error, it would seem that calling a subprocess >during platform.platform() is the culprit. But if test_subprocess passes without any bus errors, that would be strange. -- ___ Python track

[issue15589] Bus error on Debian sparc

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue15589] Bus error on Debian sparc

Stefan Krah added the comment: Setting to critical: debian-sparc 32-bit is apparently deprecated since Lenny and still uses linuxthreads. Tracking down the failure could end up in finding a platform bug like in #12936. -- priority: release blocker -> critical __

[issue15589] Bus error on Debian sparc

New submission from Stefan Krah: Running *any* test of the test suite currently produces a bus error on Debian sparc [http://people.debian.org/~aurel32/qemu/sparc/]. After the bus error, the tests seem to proceed normally though. This is definitely new. I've been testing memoryview for bus erro