Bug 695040

Summary: [abrt] yum-3.2.29-10.fc16: visit_decref: Process /usr/bin/python was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: Michal Jaegermann <michal>
Component: pythonAssignee: Dave Malcolm <dmalcolm>
Status: CLOSED DEFERRED QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: dmalcolm, ffesti, ivazqueznet, james.antill, jonathansteffan, maxamillion, pmatilai, tla
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:029d811489acebe76e8a3ccbaaa976129ff17e6b
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-03-21 18:01:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
File: backtrace none

Description Michal Jaegermann 2011-04-10 01:17:39 UTC
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.

Comment 1 Michal Jaegermann 2011-04-10 01:17:44 UTC
Created attachment 491028 [details]
File: backtrace

Comment 2 Dave Malcolm 2011-04-11 17:31:03 UTC
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).

Comment 3 Michal Jaegermann 2011-04-11 20:42:07 UTC
(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. :-)

Comment 4 Dave Malcolm 2011-04-11 21:56:11 UTC
(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 :( ]

Comment 5 Michal Jaegermann 2011-04-11 22:25:49 UTC
(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.

Comment 6 abrt-bot 2012-03-21 15:10:18 UTC
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.

Comment 7 Dave Malcolm 2012-03-21 18:01:15 UTC
Without a coredump I can't debug this further; sorry.

I'm going to close this out with resolution "DEFERRED".  Feel free to reopen.