Bug 449883 - Inkscape and Epiphany crash upon NULL dereference in gsignal while starting
Summary: Inkscape and Epiphany crash upon NULL dereference in gsignal while starting
Keywords:
Status: CLOSED DUPLICATE of bug 450790
Alias: None
Product: Fedora
Classification: Fedora
Component: glib2
Version: 9
Hardware: powerpc
OS: Linux
medium
high
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 446014 447349
TreeView+ depends on / blocked
 
Reported: 2008-06-04 05:07 UTC by Lubomir Rintel
Modified: 2008-06-12 08:04 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-06-12 08:04:59 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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 ***


Note You need to log in before you can comment on or make changes to this bug.