Issue11994
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2011-05-04 06:21 by skrah, last changed 2022-04-11 14:57 by admin. This issue is now closed.
Messages (8) | |||
---|---|---|---|
msg135098 - (view) | Author: Stefan Krah (skrah) * | Date: 2011-05-04 06:21 | |
I can reproduce this only with gcc-4.4.3, so it could also be a compiler bug. Also, the segfault only occurs when python is compiled with optimizations and run under valgrind. hg up 2.7 make distclean ./configure make valgrind --suppressions=Misc/valgrind-python.supp ./python >>> s = "-- -- --" >>> s.split('--') ==29273== Invalid read of size 4 ==29273== at 0x456C73: PyObject_Free (obmalloc.c:969) ==29273== by 0x4AD3BD: compiler_unit_free (compile.c:424) ==29273== by 0x4B6785: compiler_mod (compile.c:521) ==29273== by 0x4B69B5: PyAST_Compile (compile.c:289) ==29273== by 0x4CD564: PyRun_InteractiveOneFlags (pythonrun.c:1343) ==29273== by 0x4CD80D: PyRun_InteractiveLoopFlags (pythonrun.c:765) ==29273== by 0x4CDFFA: PyRun_AnyFileExFlags (pythonrun.c:734) ==29273== by 0x4172E9: Py_Main (main.c:599) ==29273== by 0x56F2C4C: (below main) (libc-start.c:226) ==29273== Address 0x61d3020 is not stack'd, malloc'd or (recently) free'd ==29273== ==29273== Invalid read of size 4 ==29273== at 0x456C73: PyObject_Free (obmalloc.c:969) ==29273== by 0x4B6785: compiler_mod (compile.c:521) ==29273== by 0x4B69B5: PyAST_Compile (compile.c:289) ==29273== by 0x4CD564: PyRun_InteractiveOneFlags (pythonrun.c:1343) ==29273== by 0x4CD80D: PyRun_InteractiveLoopFlags (pythonrun.c:765) ==29273== by 0x4CDFFA: PyRun_AnyFileExFlags (pythonrun.c:734) ==29273== by 0x4172E9: Py_Main (main.c:599) ==29273== by 0x56F2C4C: (below main) (libc-start.c:226) ==29273== Address 0x61d3020 is not stack'd, malloc'd or (recently) free'd ==29273== ==29273== Invalid read of size 8 ==29273== at 0x43E5A8: list_print (listobject.c:341) ==29273== by 0x454CAF: internal_print (object.c:315) ==29273== by 0x432128: PyFile_WriteObject (fileobject.c:110) ==29273== by 0x4D3857: sys_displayhook (sysmodule.c:115) ==29273== by 0x41BD66: PyObject_Call (abstract.c:2529) ==29273== by 0x4A4CB2: PyEval_CallObjectWithKeywords (ceval.c:3882) ==29273== by 0x4AA568: PyEval_EvalFrameEx (ceval.c:1739) ==29273== by 0x4ACE90: PyEval_EvalCodeEx (ceval.c:3253) ==29273== by 0x4ACFA1: PyEval_EvalCode (ceval.c:667) ==29273== by 0x4CD57E: PyRun_InteractiveOneFlags (pythonrun.c:1346) ==29273== by 0x4CD80D: PyRun_InteractiveLoopFlags (pythonrun.c:765) ==29273== by 0x4CDFFA: PyRun_AnyFileExFlags (pythonrun.c:734) ==29273== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==29273== ==29273== ==29273== Process terminating with default action of signal 11 (SIGSEGV) ==29273== Access not within mapped region at address 0x0 ==29273== at 0x43E5A8: list_print (listobject.c:341) ==29273== by 0x454CAF: internal_print (object.c:315) ==29273== by 0x432128: PyFile_WriteObject (fileobject.c:110) ==29273== by 0x4D3857: sys_displayhook (sysmodule.c:115) ==29273== by 0x41BD66: PyObject_Call (abstract.c:2529) ==29273== by 0x4A4CB2: PyEval_CallObjectWithKeywords (ceval.c:3882) ==29273== by 0x4AA568: PyEval_EvalFrameEx (ceval.c:1739) ==29273== by 0x4ACE90: PyEval_EvalCodeEx (ceval.c:3253) ==29273== by 0x4ACFA1: PyEval_EvalCode (ceval.c:667) ==29273== by 0x4CD57E: PyRun_InteractiveOneFlags (pythonrun.c:1346) ==29273== by 0x4CD80D: PyRun_InteractiveLoopFlags (pythonrun.c:765) ==29273== by 0x4CDFFA: PyRun_AnyFileExFlags (pythonrun.c:734) ==29273== If you believe this happened as a result of a stack ==29273== overflow in your program's main thread (unlikely but ==29273== possible), you can try to increase the size of the ==29273== main thread stack using the --main-stacksize= flag. ==29273== The main thread stack size used in this run was 8388608. [''==29273== ==29273== HEAP SUMMARY: ==29273== in use at exit: 2,198,606 bytes in 1,256 blocks ==29273== total heap usage: 7,315 allocs, 6,059 frees, 7,364,086 bytes allocated ==29273== ==29273== LEAK SUMMARY: ==29273== definitely lost: 0 bytes in 0 blocks ==29273== indirectly lost: 0 bytes in 0 blocks ==29273== possibly lost: 641,033 bytes in 353 blocks ==29273== still reachable: 1,557,541 bytes in 902 blocks ==29273== suppressed: 32 bytes in 1 blocks ==29273== Rerun with --leak-check=full to see details of leaked memory ==29273== ==29273== For counts of detected and suppressed errors, rerun with: -v ==29273== Use --track-origins=yes to see where uninitialised values come from ==29273== ERROR SUMMARY: 416 errors from 28 contexts (suppressed: 13 from 7) Segmentation fault |
|||
msg135099 - (view) | Author: STINNER Victor (vstinner) * | Date: 2011-05-04 07:04 | |
> I can reproduce this only with gcc-4.4.3, so it could also be a compiler bug. You should try to disable compiler optimization: pass -O0 to gcc. E.g. use ./configure --with-pydebug CFLAGS="-O0". |
|||
msg135142 - (view) | Author: Stefan Krah (skrah) * | Date: 2011-05-04 17:46 | |
STINNER Victor <report@bugs.python.org> wrote: > You should try to disable compiler optimization: pass -O0 to gcc. E.g. use ./configure --with-pydebug CFLAGS="-O0". I did, see "only occurs when python is compiled with optimizations". :) |
|||
msg135156 - (view) | Author: STINNER Victor (vstinner) * | Date: 2011-05-04 20:32 | |
GCC 4.4.3 is not the last stable version of the 4.4 branch: try maybe GCC 4.4.6... Changes of GCC 4.4.4, 4.4.5 and 4.4.6: http://gcc.gnu.org/gcc-4.4/changes.html#4.4.6 Or try maybe another major version. |
|||
msg135404 - (view) | Author: Terry J. Reedy (terry.reedy) * | Date: 2011-05-07 06:40 | |
"Also, the segfault only occurs when python is compiled with optimizations and run under valgrind." This says to me that the segfault is not a Python issue. What change do you expect in the Python source code? If none, this issue should be closed. |
|||
msg135413 - (view) | Author: Stefan Krah (skrah) * | Date: 2011-05-07 08:03 | |
Terry J. Reedy <report@bugs.python.org> wrote: > "Also, the segfault only occurs when python is > compiled with optimizations and run under valgrind." > > This says to me that the segfault is not a Python issue. > What change do you expect in the Python source code? > If none, this issue should be closed. I think that the passage you quoted is not a strong argument for closing the issue. I've been using Valgrind for several years, and I've never encountered a situation where Valgrind was wrong. This includes situations where a bug only occurs with optimizations turned on. If anything, the fact that it so far only occurs with gcc-4.3 might be a reason. Even so, recently an issue was kept open until someone (I think Victor) proved that it was a compiler bug. I'm not sure what to make of your question and its conclusion. Debugging Valgrind issues or compiler bugs takes a lot of time, so the requirement to pinpoint the exact problem in order to keep an issue open seems too strict. |
|||
msg135431 - (view) | Author: Stefan Krah (skrah) * | Date: 2011-05-07 09:51 | |
The segfault also occurs with a self-compiled gcc-4.4.6, but not with gcc-4.5.3. |
|||
msg135444 - (view) | Author: STINNER Victor (vstinner) * | Date: 2011-05-07 10:51 | |
GCC does have bugs: see a recent example with a development version of GCC 4.6 => #9880 (the bug was fixed before the final release of GCC 4.6). If you would like to go futher, you should open a bug report in GCC bug tracker (not in the Python bug tracker). |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:57:16 | admin | set | github: 56203 |
2011-05-07 10:51:40 | vstinner | set | status: open -> closed resolution: fixed messages: + msg135444 |
2011-05-07 09:51:53 | skrah | set | messages: + msg135431 |
2011-05-07 08:03:51 | skrah | set | messages: + msg135413 |
2011-05-07 06:40:00 | terry.reedy | set | nosy:
+ terry.reedy messages: + msg135404 |
2011-05-04 20:32:19 | vstinner | set | messages: + msg135156 |
2011-05-04 17:46:10 | skrah | set | messages: + msg135142 |
2011-05-04 17:06:14 | stutzbach | set | nosy:
+ stutzbach |
2011-05-04 07:04:30 | vstinner | set | nosy:
+ vstinner messages: + msg135099 |
2011-05-04 06:21:22 | skrah | create |