abrt version: 1.1.13 architecture: x86_64 Attached file: backtrace cmdline: /usr/bin/python /usr/bin/gpodder component: gpodder crash_function: node_get_last executable: /usr/bin/python kernel: 2.6.35.6-48.fc14.x86_64 package: gpodder-2.8-2.fc14 rating: 4 reason: Process /usr/bin/python was killed by signal 11 (SIGSEGV) release: Fedora release 14 (Laughlin) time: 1289275953 uid: 500 How to reproduce ----- It is not clear to me what I was doing when this happend. If I recall, I was clicking around in gpodder quickly changing values and states of a large selection of a podcast's episodes.
Created attachment 458964 [details] File: backtrace
Although gpodder was running when this bug occurred, the backtrace would suggest that python itself segfaulted so changing component. $ rpm -qa python python-2.7-8.fc14.1.x86_64
Thank you for reporting this bug. How reproducible is this problem? If you run the program from a terminal, is an error message printed? What's the output of running: $ rpm -qa gtk2 pygtk2 Looking at the backtrace, it looks like the problem occurred in thread #1 in node_get_last, deep within GTK's tree view code. From frame #20 it looks like it was responding to a row deletion event, which called a handler written in Python (frame #19 down to frame #6), which called back into GTK to get a value for column 3 from a GtkListStore (frame #5 down to frame #0). The "iter" value might be corrupt, but unfortunately, it's been optimized out so that debugger can't tell us what it was. The disassembly shows the SIGSEGV happened at: => 0x00000030e5c5cbbb <+43>: mov 0x18(%rdi),%rax with %rdi = 0xffffffe700000000 My hunch is that we're seeing a int32 vs int64 casting mismatch of an GtkTreeIter somewhere in either gtk2, pygtk2 or gpodder (does the latter contain any .c code?) - though this _is_ a hunch. Reassigning component from "python" to "gtk2"; hopefully the gtk2 maintainer will be able to figure this out further or reassign as necessary.
$ rpm -qa gtk2 pygtk2 pygtk2-2.17.0-7.fc14.x86_64 gtk2-2.22.0-1.fc14.1.x86_64 I have not been able to reproduce the bug through normal use. I recall when the bug happened I had gpodder open on a podcast with many episodes. In an effort to remove the "delete" status from all the episodes I selected the entire list, set it to "new" status then selected the entire list and unselected "new" status. Doing the above isn't enough to reproduce the bug.
This seems to be another report of bug #583450. Dave: gPodder is pure Python. Thanks for looking into this. I'll mark this bug as a duplicate. *** This bug has been marked as a duplicate of bug 583450 ***