Issue 8683: HPUX Segmentation fault in Modules/gcmodule.c -- if (!gc_list_is_empty(from)) { (original) (raw)

Created on 2010-05-11 00:51 by srid, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (6)
msg105482 - (view)	Author: Sridhar Ratnakumar (srid)	Date: 2010-05-11 00:51
Platform: HP-UX B.11.22 U ia64 Python: 2.7 trunk GDB output when running built `python` binary: Program received signal SIGSEGV, Segmentation fault (si_code: 1). 0x40000000002a2510:1 in gc_list_merge (from=0x148, to=0x148) at Modules/gcmodule.c:240 240 if (!gc_list_is_empty(from)) { and the stack trace: (gdb) bt #0 0x40000000002a2510:1 in gc_list_merge (from=0x148, to=0x148) at Modules/gcmodule.c:240 #1 0x40000000002a4720:0 in collect (generation=0) at Modules/gcmodule.c:975 #2 0x40000000002a6620:0 in _PyObject_GC_Malloc (basicsize=65598) at Modules/gcmodule.c:996 #3 0x400000000018e540:0 in PyType_GenericAlloc (type=0x1003e, nitems=65598) at Objects/typeobject.c:743 #4 0x40000000003107d0:0 in PyDescr_NewWrapper (type=0x0, base=0x1003e, wrapped=0x1003e) at Objects/descrobject.c:641 #5 0x40000000001a4570:0 in add_operators (type=0x0) at Objects/typeobject.c:6388 #6 0x4000000000193670:0 in PyType_Ready (type=0x1003e) at Objects/typeobject.c:4003 #7 0x40000000001485b0:0 in _Py_ReadyTypes () at Objects/object.c:2092 #8 0x4000000000270980:0 in Py_InitializeEx (install_sigs=0) at Python/pythonrun.c:176 #9 0x40000000002720e0:0 in Py_Initialize () at Python/pythonrun.c:370 #10 0x400000000009da70:0 in Py_Main (argc=0, argv=0x0) at Modules/main.c:507 #11 0x400000000009c770:0 in main (argc=0, argv=0x0) at ./Modules/python.c:23
msg105528 - (view)	Author: Sridhar Ratnakumar (srid)	Date: 2010-05-11 17:39
Still debugging it. In gcmodule.c:collect(..) the value of the variable `generation` is 80 - shouldn't it be less than NUM_GENERATIONS (3)?
msg105529 - (view)	Author: Antoine Pitrou (pitrou) *	Date: 2010-05-11 17:55
> Still debugging it. In gcmodule.c:collect(..) the value of the > variable `generation` is 80 - shouldn't it be less than > NUM_GENERATIONS (3)? Certainly. Have you tried using different optimization options? Which compiler are you using?
msg105531 - (view)	Author: Sridhar Ratnakumar (srid)	Date: 2010-05-11 18:04
I am using "cc: HP aC++/ANSI C B3910B A.05.55 [Dec 04 2003]" .. with the following options. cc +DD64 -Ae -D_REENTRANT +Z -c -g -DNDEBUG -O -I. -IInclude -I./Include -DPy_BUILD_CORE -o Modules/gcmodule.o Modules/gcmodule.c So that is +O2 level. ---- Interestingly the following patch fixes the bug, and shows that this is a optimization bug in HPUX compiler: diff -r 549fd95a5eb9 Modules/gcmodule.c --- a/Modules/gcmodule.c Mon May 10 23:51:33 2010 +0200 +++ b/Modules/gcmodule.c Tue May 11 11:02:52 2010 -0700 @@ -984,7 +984,8 @@ /* Find the oldest generation (highest numbered) where the count * exceeds the threshold. Objects in the that generation and * generations younger than it will be collected. */ - for (i = NUM_GENERATIONS-1; i >= 0; i--) { + i = NUM_GENERATIONS-1; + while (i>=0){ if (generations[i].count > generations[i].threshold) { /* Avoid quadratic performance degradation in number of tracked objects. See comments at the beginning @@ -996,6 +997,7 @@ n = collect(i); break; } + i--; } return n; } ---- I will try to use a different optimization level now.
msg105534 - (view)	Author: Sridhar Ratnakumar (srid)	Date: 2010-05-11 18:43
Using OPT="-O1" fixes this issue. Please feel free to close it.
msg105556 - (view)	Author: Antoine Pitrou (pitrou) *	Date: 2010-05-11 22:44
Ok, I'm closing. Thank you for testing Python, anyway!