Hide Forgot
abrt version: 1.1.17 architecture: x86_64 Attached file: backtrace, 73897 bytes cmdline: /usr/bin/python /usr/bin/yum list available *applet* comment: No idea how to reproduce. Repeated command run without any fireworks. component: yum Attached file: coredump, 9977856 bytes crash_function: visit_decref executable: /usr/bin/python kernel: 2.6.38-0.rc7.git2.3.fc16.x86_64 package: yum-3.2.29-10.fc16 rating: 4 reason: Process /usr/bin/python was killed by signal 11 (SIGSEGV) release: Fedora release 16 (Rawhide) time: 1302397197 uid: 0 How to reproduce ----- 1. Typed yum list available *applet*' and got segementation fault.
Created attachment 491028 [details] File: backtrace
Thanks for filing this. Do you have a core dump? (It's a crash inside Python's garbage collector: something is wrong with a pointer or reference count _somewhere_ inside the process. Identifying exactly what the bug is is likely to be difficult, alas).
(In reply to comment #2) > Thanks for filing this. Do you have a core dump? Yes. There is 'coredump' collected by abrt. As a matter of fact 'abrt' wrote: "Attached file: coredump, 9977856 bytes" but I really do not know where "attached". All of the above is 'abrt' doing. If you want me to attach this file separately do you mind if I will compress it first? > (It's a crash inside Python's garbage collector: something is wrong with a > pointer or reference count _somewhere_ inside the process. Identifying exactly > what the bug is is likely to be difficult, alas). I realize that. Most likely something got clobbered but exactly how could be hard to guess/repeat. Stil SIGSEGV from python got my attention. :-)
(In reply to comment #3) > (In reply to comment #2) > > Thanks for filing this. Do you have a core dump? > > Yes. There is 'coredump' collected by abrt. As a matter of fact 'abrt' wrote: > "Attached file: coredump, 9977856 bytes" but I really do not know where > "attached". All of the above is 'abrt' doing. > > If you want me to attach this file separately do you mind if I will compress > it first? Compressing it would be a good idea. If you're going to attach the coredump, please also attach the result of "rpm -qa" as it won't be useful without it (my guess is that it's a bug in a C extension module, though that's a guess). Also, please note that the coredump contains all data that was in the memory of the process at the time of the crash. It may or may not contain information that you'd regard as private. (Feel free to email me the compressed coredump, if you're more comfortable with that). [Also, I have many duties, and I can't guarantee that I'll be able to spend much time debugging this within a short timespan :( ]
(In reply to comment #4) > > If you're going to attach the coredump, > please also attach the result of "rpm -qa" as it won't be useful without it You are in luck that just yesterday there was practically no rawhide updates. :-) > (Feel free to email me the compressed coredump, > if you're more comfortable with that). Thanks for the offer. I will just do that even if this is from a "scratch" system running rawhide so core is not likely to contain much of sensitive data. Just in case. > [Also, I have many duties, and I can't guarantee that I'll be able to spend > much time debugging this within a short timespan :( ] This is the first time I have seen a segfault of such kind. If it will happen again I will surely let you know.
Backtrace analysis found this bug to be similar to bug #668330 from component abrt. You might want to check that bug for additional information. This comment is automatically generated.
Without a coredump I can't debug this further; sorry. I'm going to close this out with resolution "DEFERRED". Feel free to reopen.