Bug 449883

Summary: Inkscape and Epiphany crash upon NULL dereference in gsignal while starting
Product: [Fedora] Fedora Reporter: Lubomir Rintel <lkundrak>
Component: glib2Assignee: Matthias Clasen <mclasen>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: medium    
Version: 9CC: albrecht.dress, elliot.paquette, lkundrak, mike, mmahut, quartz
Target Milestone: ---   
Target Release: ---   
Hardware: powerpc   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-06-12 08:04:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 446014, 447349    

Description Lubomir Rintel 2008-06-04 05:07:31 UTC
Some glib applications, including Inkscape (bug #447349) and Epihpany (bug
#446014) can not start, as they crash after NULL pointer dereference. Both
crashes trace back into gsignal, which makes me believe that it might not be an
application error, but an error in some library, possibly glib.

Backtrace from Inkscape:
https://bugzilla.redhat.com/attachment.cgi?id=305989

Backtrace from Epiphany:
https://bugzilla.redhat.com/attachment.cgi?id=305073

Comment 1 David Woodhouse 2008-06-12 08:04:59 UTC
This is what I've spent the last day or so staring at. When I start up epiphany,
it hits my breakpoint in signal_emit_unlocked_R 86 times or so, and on the last
occasion I can happily either use 'fini' or manually step to the end of the
function and long beyond. It _isn't_ crashing in that 86th invocation of the
function.

Yet when I let it continue, it crashes in signal_emit_unlocked_R() without ever
hitting my breakpoint at the start of that function. It'll hit a breakpoint
_later_ in that function, but not near the start. I am very confused.

It's almost as if a stray return is dumping us into that function. Although the
backtrace does look sane.

When the first cup of tea of the morning has taken effect, I'm going to start by
auditing the use of va_lists in the calling function -- abuse of va_list is
frequent, and could have bizarre effects which _might_ include this, somehow.


*** This bug has been marked as a duplicate of 450790 ***