classification
Title: Segfault in PyFile_SoftSpace/PyEval_EvalFrameEx with sys.stdout reassigned
Type: crash Stage:
Components: Versions:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: amaury.forgeotdarc, benjamin.peterson, brodie
Priority: normal Keywords: patch

Created on 2008-06-30 06:04 by brodie, last changed 2008-07-01 21:02 by amaury.forgeotdarc. This issue is now closed.

Files
File name Uploaded Description Edit
crash5.py brodie, 2008-06-30 06:04
print.patch amaury.forgeotdarc, 2008-07-01 08:59
Messages (9)
msg68993 - (view) Author: Brodie Rao (brodie) Date: 2008-06-30 06:04
Running the attached script - which reassigns sys.stdout to an object 
that proxies sys.stdout, and eventually reassigns it back to the 
original object - using Apple's distribution of Python 2.5.1 on an x86 
machine, I get the following crash:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000000007d312298
Crashed Thread:  0

Thread 0 Crashed:
0   ???                             0x00025d33 0 + 154931
1   org.python.python               0x001381c1 PyFloat_FromString + 6196
2   org.python.python               0x001381c1 PyFloat_FromString + 6196
3   org.python.python               0x0014cdce _PyTrash_destroy_chain + 
89
4   org.python.python               0x00198bd3 PyErr_Clear + 34
5   org.python.python               0x00132938 PyFile_SoftSpace + 117
6   org.python.python               0x0018b273 PyEval_EvalFrameEx + 7497
7   org.python.python               0x0018f45b PyEval_EvalCodeEx + 1638
8   org.python.python               0x0018f548 PyEval_EvalCode + 87
9   org.python.python               0x001a69ec PyErr_Display + 1896
10  org.python.python               0x001a7016 PyRun_FileExFlags + 135
11  org.python.python               0x001a8982 PyRun_SimpleFileExFlags + 
421
12  org.python.python               0x001b3c03 Py_Main + 3095
13  org.python.pythonapp            0x00001fca 0x1000 + 4042

During the process of whittling down the script to a test case, I 
experienced other kinds of crashes, or no crash at all. For each 
iteration of the script, the outcome was always the same, i.e. never 
inconsistent between runs.

All the various crashes I've encountered:

   :Assertion failed: (gc->gc.gc_refs != 0), function visit_decref, file 
Modules
/gcmodule.c, line 276.

   Assertion failed: (pool->ref.count > 0), function PyObject_Free, file 
Objects
/obmalloc.c, line 929.

   [1]    33289 illegal hardware instruction  python crash.py

   [1]    33352 floating point exception  python crash.py

   [1]    33502 segmentation fault  python crash.py

   [1]    34303 bus error  python crash.py

Running this on a different machine running Debian Etch Linux x86 using 
Debian's Python 2.4 distribution, I get the following crash:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209882400 (LWP 21471)]
0x080b9ffc in PyEval_EvalCodeEx ()
(gdb) bt
#0  0x080b9ffc in PyEval_EvalCodeEx ()
#1  0x08100b69 in PyClassMethod_New ()
#2  0x0805ad9c in PyObject_CallFunction ()
#3  0x08097594 in PyType_Ready ()
#4  0x080b79bf in PyEval_EvalFrame ()
#5  0x080ba755 in PyEval_EvalCodeEx ()
#6  0x08100b69 in PyClassMethod_New ()
#7  0x0805ad9c in PyObject_CallFunction ()
#8  0x08097594 in PyType_Ready ()
#9  0x080b79bf in PyEval_EvalFrame ()
#10 0x080ba755 in PyEval_EvalCodeEx ()
#11 0x08100b69 in PyClassMethod_New ()
#12 0x0805ad9c in PyObject_CallFunction ()
#13 0x08097594 in PyType_Ready ()
#14 0x080b79bf in PyEval_EvalFrame ()
[the same stack trace repeating over and over...]
#141 0x08100b69 in PyClassMethod_New ()
#142 0x0805ad9c in PyObject_CallFunction ()
#143 0x08097594 in PyType_Ready ()
#144 0x080b79bf in PyEval_EvalFrame ()
#145 0x080ba755 in PyEval_EvalCodeEx ()
#146 0x08100b69 in PyClassMethod_New ()
#147 0x0805ad9c in PyObject_CallFunction ()
#148 0x08097594 in PyType_Ready ()
#149 0x0807e5e9 in PyObject_GetAttrString ()
#150 0x08064f91 in PyFile_SoftSpace ()
#151 0x080b6420 in PyEval_EvalFrame ()
#152 0x080ba755 in PyEval_EvalCodeEx ()
#153 0x080ba7b9 in PyEval_EvalCode ()
#154 0x080dd167 in PyRun_FileExFlags ()
#155 0x080dd364 in PyRun_SimpleFileExFlags ()
#156 0x08055ba8 in Py_Main ()
#157 0x08055032 in main ()

Using Debian's distribution of Python 2.5, I didn't see any crashes.

Using the distribution of Python 2.6b1 from python.org on Mac OS X 10.5 
(x86), I saw the same crash:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000bea0
0x001b7e50 in ?? ()
(gdb) bt
#0  0x001b7e50 in ?? ()
#1  0x0002bea1 in frame_dealloc (f=0x21db20) at 
Objects/frameobject.c:417
#2  0x0002bf55 in frame_dealloc (f=0x21f220) at 
Objects/frameobject.c:425
#3  0x0002bf55 in frame_dealloc (f=0x21f380) at 
Objects/frameobject.c:425
#4  0x000466db in _PyTrash_destroy_chain () at Objects/object.c:2223
#5  0x000b2dd2 in PyErr_Clear () at Python/errors.c:239
#6  0x00024235 in PyFile_SoftSpace (f=0x3645b0, newflag=0) at 
Objects/fileobject.c:2141
#7  0x000a11e4 in PyEval_EvalFrameEx (f=0x202f20, throwflag=0) at 
Python/ceval.c:1622
#8  0x000a45ea in PyEval_EvalCodeEx (co=0x33e968, globals=0x1b7e40, 
locals=0x1b7e40, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
defcount=0, closure=0x0) at Python/ceval.c:2880
#9  0x000a46f7 in PyEval_EvalCode (co=0x21eddc, globals=0x21eddc, 
locals=0x21eddc) at Python/ceval.c:495
#10 0x000c99d3 in PyRun_FileExFlags (fp=0xa0125de0, filename=0xbffff0ec 
"/Users/brodie/Documents/Code/py-crash/crash5.py", start=257, 
globals=0x1b7e40, locals=0x1b7e40, closeit=1, flags=0xbfffef5c) at 
Python/pythonrun.c:1300
#11 0x000c9e53 in PyRun_SimpleFileExFlags (fp=<value temporarily 
unavailable, due to optimizations>, filename=0xbffff0ec 
"/Users/brodie/Documents/Code/py-crash/crash5.py", closeit=1, 
flags=0xbfffef5c) at Python/pythonrun.c:896
#12 0x000da844 in Py_Main (argc=1, argv=0xbfffefdc) at 
Modules/main.c:575
#13 0x00001c3c in _start ()
#14 0x00001b69 in start ()

I should note that I reduced the test case as much as I possibly could, 
and the actual compiled source seems to affect the crash. I.e., if I 
remove one of the unused imports, it doesn't crash; if I remove the 
unused function foo(), it doesn't crash; if I change the "height" 
variable passed to wrap_output(), it doesn't crash; if I remove the 
reassignment of buf[0] in flush(), it doesn't crash.

I'm not sure if these crashes are due to an error in the script, or if 
the script should even be capable of crashing Python in this manner.
msg68994 - (view) Author: Brodie Rao (brodie) Date: 2008-06-30 06:39
Actually, this seems to be a hardware issue, despite the consistency 
between runs and the duplication on another machine. I think you can 
ignore/close this bug. Sorry for the noise.
msg69029 - (view) Author: Brodie Rao (brodie) Date: 2008-06-30 23:41
Actually, I've tested this script on another Debian x86 machine and two 
Ubuntu x86 machines, all which exhibit the exact same crash with their 
Python 2.4 distributions. I don't think it's a hardware issue, I think 
there's a legitimate issue here. The crash always originates from 
PyFile_SoftSpace in PyEval_EvalFrameEx.
msg69030 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-06-30 23:59
Can you try on later versions of Python. 2.4 is no longer supported.
msg69036 - (view) Author: Brodie Rao (brodie) Date: 2008-07-01 00:41
Using Python 2.5.2 from python.org on Mac OS X 10.5, I get the same 
error:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000ad40
0x0052ed30 in ?? ()
(gdb) bt
#0  0x0052ed30 in ?? ()
#1  0x0002ad41 in frame_dealloc (f=0x61cca0) at 
Objects/frameobject.c:416
#2  0x0002adf2 in frame_dealloc (f=0x61ea10) at 
Objects/frameobject.c:424
#3  0x0002adf2 in frame_dealloc (f=0x61eb70) at 
Objects/frameobject.c:424
#4  0x0004574b in _PyTrash_destroy_chain () at Objects/object.c:2136
#5  0x000aebc2 in PyErr_Clear () at Python/errors.c:231
#6  0x000234fb in PyFile_SoftSpace (f=0x700cb0, newflag=0) at 
Objects/fileobject.c:2127
#7  0x0009b819 in PyEval_EvalFrameEx (f=0x61b840, throwflag=0) at 
Python/ceval.c:1608
#8  0x0009f29a in PyEval_EvalCodeEx (co=0x595410, globals=0x52ed20, 
locals=0x52ed20, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
defcount=0, closure=0x0) at Python/ceval.c:2836
#9  0x0009f3a7 in PyEval_EvalCode (co=0x595410, globals=0x52ed20, 
locals=0x52ed20) at Python/ceval.c:494
#10 0x000c31d7 in PyRun_FileExFlags (fp=0xa0125de0, filename=0xbffff0cc, 
start=257, globals=0x52ed20, locals=0x52ed20, closeit=1, 
flags=0xbfffef3c) at Python/pythonrun.c:1273
#11 0x000c3583 in PyRun_SimpleFileExFlags (fp=0xa0125de0, 
filename=0xbffff0cc, closeit=1, flags=0xbfffef3c) at 
Python/pythonrun.c:879
#12 0x000d1d27 in Py_Main (argc=1, argv=0xbfffefb8) at 
Modules/main.c:523
#13 0x00001bcc in _start ()
#14 0x00001af9 in start ()
(gdb) info locals
No symbol table info available.
(gdb) up
#1  0x0002ad41 in frame_dealloc (f=0x61cca0) at 
Objects/frameobject.c:416
416	                Py_CLEAR(*p);
(gdb) info locals
p = (PyObject **) 0x61cdd8
valuestack = (PyObject **) 0x61cde0
co = (PyCodeObject *) 0x61cdd8
f = (PyFrameObject *) 0x61cca0

[...]

(gdb) up
#6  0x000234fb in PyFile_SoftSpace (f=0x700cb0, newflag=0) at 
Objects/fileobject.c:2127
2127				PyErr_Clear();
(gdb) info locals
v = (PyObject *) 0x0
oldflag = 0
f = (PyObject *) 0x700cb0
(gdb) up
#7  0x0009b819 in PyEval_EvalFrameEx (f=0x61b840, throwflag=0) at 
Python/ceval.c:1608
1608						PyFile_SoftSpace(w, 0);
(gdb) info locals
stack_pointer = (PyObject **) 0x0
next_instr = (unsigned char *) 0x61e5e0 "?(\r"
opcode = 0
oparg = 7343280
why = 7343280
err = 0
x = (PyObject *) 0x0
v = (PyObject *) 0x700cb0
w = (PyObject *) 0xffffffff
u = (PyObject *) 0x700cb0
t = (PyObject *) 0x0
stream = (PyObject *) 0x0
fastlocals = (PyObject **) 0x61b978
freevars = (PyObject **) 0x61b978
retval = (PyObject *) 0x0
tstate = (PyThreadState *) 0x600170
co = (PyCodeObject *) 0x595410
instr_ub = -1
instr_lb = 0
instr_prev = -1
first_instr = (unsigned char *) 0x704034 "d"
names = (PyObject *) 0x58a4b0
consts = (PyObject *) 0x597ab0

From what I see on python.org, the advertised policy is to fix bugs 
affecting the stability of the interpreter. I don't know if it's 
relevant to the 2.5 crash, but using Python 2.4.5 from python.org on 
Debian x86 I'm able to get a more detailed backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210747200 (LWP 11771)]
PyEval_EvalCodeEx (co=0xb7cf7ba0, globals=0xb7d30824, locals=0x0, 
args=0xb7cfd9b8, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0) at Python/ceval.c:2571
2571				Py_INCREF(x);
(gdb) bt
#0  PyEval_EvalCodeEx (co=0xb7cf7ba0, globals=0xb7d30824, locals=0x0, 
args=0xb7cfd9b8, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0) at Python/ceval.c:2571
#1  0x080ffab9 in function_call (func=0xb7d00064, arg=0xb7cfd9ac, 
kw=0x0) at Objects/funcobject.c:548
#2  0x0805adbc in PyObject_CallFunction (callable=0xb7d00064, 
format=0x8115c8b "OO") at Objects/abstract.c:1795
#3  0x08097634 in slot_tp_getattr_hook (self=0xb7cfd9ac, 
name=0xb7cfdc60) at Objects/typeobject.c:4607
#4  0x080b69b2 in PyEval_EvalFrame (f=0x81a5b6c) at Python/ceval.c:1957

[with the same stack trace as above continuing...]

#155 0x080b9785 in PyEval_EvalCodeEx (co=0xb7cf7ba0, globals=0xb7d30824, 
locals=0x0, args=0xb7cfde58, argcount=2, kws=0x0, kwcount=0, defs=0x0, 
defcount=0, closure=0x0) at Python/ceval.c:2741
#156 0x080ffab9 in function_call (func=0xb7d00064, arg=0xb7cfde4c, 
kw=0x0) at Objects/funcobject.c:548
#157 0x0805adbc in PyObject_CallFunction (callable=0xb7d00064, 
format=0x8115c8b "OO") at Objects/abstract.c:1795
#158 0x08097634 in slot_tp_getattr_hook (self=0xb7cfd9ac, 
name=0xb7cfdc60) at Objects/typeobject.c:4607
#159 0x080b69b2 in PyEval_EvalFrame (f=0x81a9084) at Python/ceval.c:1957
#160 0x080b9785 in PyEval_EvalCodeEx (co=0xb7cf7ba0, globals=0xb7d30824, 
locals=0x0, args=0xb7cfde98, argcount=2, kws=0x0, kwcount=0, defs=0x0, 
defcount=0, closure=0x0) at Python/ceval.c:2741
#161 0x080ffab9 in function_call (func=0xb7d00064, arg=0xb7cfde8c, 
kw=0x0) at Objects/funcobject.c:548
#162 0x0805adbc in PyObject_CallFunction (callable=0xb7d00064, 
format=0x8115c8b "OO") at Objects/abstract.c:1795
#163 0x08097634 in slot_tp_getattr_hook (self=0xb7cfd9ac, 
name=0xb7ce8c78) at Objects/typeobject.c:4607
#164 0x0807e6a9 in PyObject_GetAttrString (v=0xb7cfd9ac, name=0x810748e 
"softspace") at Objects/object.c:1031
#165 0x08064fb1 in PyFile_SoftSpace (f=0xb7cfd9ac, newflag=0) at 
Objects/fileobject.c:1994
#166 0x080b540e in PyEval_EvalFrame (f=0x81a2ac4) at Python/ceval.c:1584
#167 0x080b9785 in PyEval_EvalCodeEx (co=0xb7cf7ce0, globals=0xb7d30824, 
locals=0xb7d30824, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
defcount=0, closure=0x0) at Python/ceval.c:2741
#168 0x080b97e9 in PyEval_EvalCode (co=0xb7cf7ce0, globals=0xb7d30824, 
locals=0xb7d30824) at Python/ceval.c:484
#169 0x080dc097 in PyRun_FileExFlags (fp=0x8145008, filename=0xbf9239e3 
"[...]/crash5.py", start=257, globals=0xb7d30824, locals=0xb7d30824, 
closeit=1, flags=0xbf9228f4) at Python/pythonrun.c:1287
#170 0x080dc294 in PyRun_SimpleFileExFlags (fp=0x8145008, 
filename=0xbf9239e3 "[...]/crash5.py", closeit=1, flags=0xbf9228f4) at 
Python/pythonrun.c:871
#171 0x08055bc8 in Py_Main (argc=1, argv=0xbf9229b4) at 
Modules/main.c:493
#172 0x08055052 in main (argc=Cannot access memory at address 0x2
) at Modules/python.c:23

Locals:

(gdb) info locals
i = 0
n = 2
kwdict = (PyObject *) 0x0
f = (PyFrameObject *) 0x81a5ce4
retval = <value optimized out>
fastlocals = (PyObject **) 0x81a5e30
freevars = (PyObject **) 0x81a5e38
tstate = (PyThreadState *) 0x81451b0
x = (PyObject *) 0x0
u = <value optimized out>

I can't reproduce the crash on Linux with Python 2.5.
msg69038 - (view) Author: Brodie Rao (brodie) Date: 2008-07-01 01:04
Running with Python 2.5.2 with guard malloc on OS X 10.5 produces a 
similar crash to that of Python 2.4 on Linux:

(gdb) set env DYLD_INSERT_LIBRARIES /usr/lib/libgmalloc.dylib
(gdb) run ~/Documents/Code/py-crash/crash5.py
Starting program: /Users/brodie/Downloads/Python-2.5.2/python.exe 
~/Documents/Code/py-crash/crash5.py
GuardMalloc: Allocations will be placed on 16 byte boundaries.
GuardMalloc:  - Some buffer overruns may not be noticed.
GuardMalloc:  - Applications using vector instructions (e.g., SSE or 
Altivec) should work.
GuardMalloc: GuardMalloc version 18
GuardMalloc: Allocations will be placed on 16 byte boundaries.
GuardMalloc:  - Some buffer overruns may not be noticed.
GuardMalloc:  - Applications using vector instructions (e.g., SSE or 
Altivec) should work.
GuardMalloc: GuardMalloc version 18
Reading symbols for shared libraries +. done
Reading symbols for shared libraries .. done
GuardMalloc: Allocations will be placed on 16 byte boundaries.
GuardMalloc:  - Some buffer overruns may not be noticed.
GuardMalloc:  - Applications using vector instructions (e.g., SSE or 
Altivec) should work.
GuardMalloc: GuardMalloc version 18

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xb2f79e88
0x00044951 in PyObject_GetAttr (v=0xb2de7c50, name=0xb2de79c0) at 
Objects/object.c:1126
1126		if (tp->tp_getattro != NULL)
(gdb) info locals
tp = (PyTypeObject *) 0xb2f79e40
v = (PyObject *) 0xb2de7c50
name = (PyObject *) 0xb2de79c0
(gdb) print tp->tp_getattro
Cannot access memory at address 0xb2f79e88
(gdb) bt
#0  0x00044951 in PyObject_GetAttr (v=0xb2de7c50, name=0xb2de79c0) at 
Objects/object.c:1126
#1  0x00099409 in PyEval_EvalFrameEx (f=0xb31fdeb0, throwflag=0) at 
Python/ceval.c:1990
#2  0x0009f29a in PyEval_EvalCodeEx (co=0xb060ef50, globals=0xb002fd20, 
locals=0x0, args=0xb2dee8fc, argcount=2, kws=0x0, kwcount=0, defs=0x0, 
defcount=0, closure=0x0) at Python/ceval.c:2836
#3  0x0002c8ea in function_call (func=0xb0623cf0, arg=0xb2dee8f0, 
kw=0x0) at Objects/funcobject.c:517
#4  0x00008b07 in PyObject_CallFunctionObjArgs (callable=0xb0623cf0) at 
Objects/abstract.c:1861
#5  0x00068e05 in slot_tp_getattr_hook (self=0xb2de7c50, 
name=0xb2de79c0) at Objects/typeobject.c:4775
#6  0x00099409 in PyEval_EvalFrameEx (f=0xb31fbeb0, throwflag=0) at 
Python/ceval.c:1990
#7  0x0009f29a in PyEval_EvalCodeEx (co=0xb060ef50, globals=0xb002fd20, 
locals=0x0, args=0xb2dee8d4, argcount=2, kws=0x0, kwcount=0, defs=0x0, 
defcount=0, closure=0x0) at Python/ceval.c:2836
#8  0x0002c8ea in function_call (func=0xb0623cf0, arg=0xb2dee8c8, 
kw=0x0) at Objects/funcobject.c:517
#9  0x00008b07 in PyObject_CallFunctionObjArgs (callable=0xb0623cf0) at 
Objects/abstract.c:1861
#10 0x00068e05 in slot_tp_getattr_hook (self=0xb2de7c50, 
name=0xb2de79c0) at Objects/typeobject.c:4775
#11 0x00099409 in PyEval_EvalFrameEx (f=0xb31f9eb0, throwflag=0) at 
Python/ceval.c:1990
#12 0x0009f29a in PyEval_EvalCodeEx (co=0xb060ef50, globals=0xb002fd20, 
locals=0x0, args=0xb2dee8ac, argcount=2, kws=0x0, kwcount=0, defs=0x0, 
defcount=0, closure=0x0) at Python/ceval.c:2836
#13 0x0002c8ea in function_call (func=0xb0623cf0, arg=0xb2dee8a0, 
kw=0x0) at Objects/funcobject.c:517
#14 0x00008b07 in PyObject_CallFunctionObjArgs (callable=0xb0623cf0) at 
Objects/abstract.c:1861
#15 0x00068e05 in slot_tp_getattr_hook (self=0xb2de7c50, 
name=0xb2de79c0) at Objects/typeobject.c:4775
#16 0x00099409 in PyEval_EvalFrameEx (f=0xb31f7eb0, throwflag=0) at 
Python/ceval.c:1990
#17 0x0009f29a in PyEval_EvalCodeEx (co=0xb060ef50, globals=0xb002fd20, 
locals=0x0, args=0xb2dee884, argcount=2, kws=0x0, kwcount=0, defs=0x0, 
defcount=0, closure=0x0) at Python/ceval.c:2836
#18 0x0002c8ea in function_call (func=0xb0623cf0, arg=0xb2dee878, 
kw=0x0) at Objects/funcobject.c:517
#19 0x00008b07 in PyObject_CallFunctionObjArgs (callable=0xb0623cf0) at 
Objects/abstract.c:1861
#20 0x00068e05 in slot_tp_getattr_hook (self=0xb2de7c50, 
name=0xb2de79c0) at Objects/typeobject.c:4775

[...]

#1554 0x00008b07 in PyObject_CallFunctionObjArgs (callable=0xb0623cf0) 
at Objects/abstract.c:1861
#1555 0x00068e05 in slot_tp_getattr_hook (self=0xb2de7c50, 
name=0xb2de79c0) at Objects/typeobject.c:4775
#1556 0x00099409 in PyEval_EvalFrameEx (f=0xb2f8beb0, throwflag=0) at 
Python/ceval.c:1990
#1557 0x0009f29a in PyEval_EvalCodeEx (co=0xb060ef50, 
globals=0xb002fd20, locals=0x0, args=0xb2de967c, argcount=2, kws=0x0, 
kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2836
#1558 0x0002c8ea in function_call (func=0xb0623cf0, arg=0xb2de9670, 
kw=0x0) at Objects/funcobject.c:517
#1559 0x00008b07 in PyObject_CallFunctionObjArgs (callable=0xb0623cf0) 
at Objects/abstract.c:1861
#1560 0x00068e05 in slot_tp_getattr_hook (self=0xb2de7c50, 
name=0xb060d5c0) at Objects/typeobject.c:4775
#1561 0x00044a66 in PyObject_GetAttrString (v=0xb2de7c50, name=0xed255) 
at Objects/object.c:1069
#1562 0x00023455 in PyFile_SoftSpace (f=0xb2de7c50, newflag=0) at 
Objects/fileobject.c:2125
#1563 0x0009b819 in PyEval_EvalFrameEx (f=0xb2f51ea0, throwflag=0) at 
Python/ceval.c:1608
#1564 0x0009f29a in PyEval_EvalCodeEx (co=0xb0621410, 
globals=0xb002fd20, locals=0xb002fd20, args=0x0, argcount=0, kws=0x0, 
kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2836
#1565 0x0009f3a7 in PyEval_EvalCode (co=0xb0621410, globals=0xb002fd20, 
locals=0xb002fd20) at Python/ceval.c:494
#1566 0x000c31d7 in PyRun_FileExFlags (fp=0xa0125de0, 
filename=0xbffff06c, start=257, globals=0xb002fd20, locals=0xb002fd20, 
closeit=1, flags=0xbfffeecc) at Python/pythonrun.c:1273
#1567 0x000c3583 in PyRun_SimpleFileExFlags (fp=0xa0125de0, 
filename=0xbffff06c, closeit=1, flags=0xbfffeecc) at 
Python/pythonrun.c:879
#1568 0x000d1d27 in Py_Main (argc=1, argv=0xbfffef54) at 
Modules/main.c:523
#1569 0x00001bcc in _start ()
#1570 0x00001af9 in start ()
msg69040 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-07-01 08:59
I reproduced the problem on windows, and it is indeed a problem with the
"print" statement, when the write() method reassigns sys.stdout: the
code calls PyFile_WriteString(), then PyFile_SoftSpace on the same
object, which has been freed in your case.
A pair of INCREF/DECREF did the trick. See attached patch.
msg69050 - (view) Author: Brodie Rao (brodie) Date: 2008-07-01 16:11
Thanks. The patch fixes the crash for me on Python 2.5.2 and 2.6b1 on OS X 
and Python 2.4.5 on Debian and Ubuntu.
msg69076 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-07-01 21:02
Corrected as r64633 (trunk) and r64639 (release25-maint). version 3.0 is
not affected, and there won't be any more 2.4 release.

Thanks for the report!
History
Date User Action Args
2008-07-01 21:02:23amaury.forgeotdarcsetstatus: open -> closed
resolution: fixed
messages: + msg69076
2008-07-01 16:11:32brodiesetmessages: + msg69050
2008-07-01 08:59:22amaury.forgeotdarcsetfiles: + print.patch
keywords: + patch
messages: + msg69040
nosy: + amaury.forgeotdarc
2008-07-01 01:04:35brodiesetmessages: + msg69038
2008-07-01 00:41:17brodiesetmessages: + msg69036
2008-06-30 23:59:42benjamin.petersonsetstatus: closed -> open
resolution: not a bug -> (no value)
messages: + msg69030
nosy: + benjamin.peterson
2008-06-30 23:41:34brodiesetmessages: + msg69029
2008-06-30 08:25:15georg.brandlsetstatus: open -> closed
resolution: not a bug
2008-06-30 06:39:17brodiesetmessages: + msg68994
2008-06-30 06:04:11brodiecreate