classification
Title: [2.7/gcc-4.4.3] Segfault under valgrind in string.split()
Type: crash Stage:
Components: Interpreter Core Versions: Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: skrah, stutzbach, terry.reedy, vstinner
Priority: normal Keywords:

Created on 2011-05-04 06:21 by skrah, last changed 2011-05-07 10:51 by vstinner. This issue is now closed.

Messages (8)
msg135098 - (view) Author: Stefan Krah (skrah) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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
2011-05-07 10:51:40vstinnersetstatus: open -> closed
resolution: fixed
messages: + msg135444
2011-05-07 09:51:53skrahsetmessages: + msg135431
2011-05-07 08:03:51skrahsetmessages: + msg135413
2011-05-07 06:40:00terry.reedysetnosy: + terry.reedy
messages: + msg135404
2011-05-04 20:32:19vstinnersetmessages: + msg135156
2011-05-04 17:46:10skrahsetmessages: + msg135142
2011-05-04 17:06:14stutzbachsetnosy: + stutzbach
2011-05-04 07:04:30vstinnersetnosy: + vstinner
messages: + msg135099
2011-05-04 06:21:22skrahcreate