abrt detected a crash.
How to reproduce
This was inside gdb. I'll paste the log of the session.
Process was terminated by signal 11
Created attachment 367187 [details]
I was attempting to use the gdbinit file supplied with python-devel. I started with a simple scenario, and I'm getting segfaults. I'll attach logs of two sessions with gdb.
Created attachment 367188 [details]
log from initial session
Created attachment 367189 [details]
log from session with "set unwindonsignal on"
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.
More information and reason for this action is here:
Thanks for filing this report.
Looking over attachment 367188 [details], what I believe happened here is:
- you ran python under gdb
- you started the inferior python process, which brought up the interactive console
- you created a python variable in the interactive console ("a=1")
- you used Ctrl-C to break back into gdb.
- you then ran "pyo a" (in gdb)
- gdb found a variable named "a" at the C level (which bears no relationship to the naming at the Python level), and attempted to interpret it as a (struct PyObject*), running the "pyo" command defined in the gdbinit file.
- this ran "print _PyObject_Dump($arg0)" upon this "a"
- this caused gdb to inject a call to _PyObject_Dump(a) into the inferior process, casting the value of "a" (in gdb) to a struct PyObject*, when it probably isn't one.
- inferior process tries to run this code upon arbitrary data -> SEGFAULT
You can see this in the backtrace: frame 3 and below is where the inferior process was halted, frame 2 is the injected call from gdb, and frame 1 and 0 are the attempt to run _PyObject_Dump upon op=0x3e4bb67a00000000
So I believe this was user-error, but clearly this feature is fragile and hard-to-use. I'm hoping to improve the debuggability of Python, see: