Bug 449883 - Inkscape and Epiphany crash upon NULL dereference in gsignal while starting
Inkscape and Epiphany crash upon NULL dereference in gsignal while starting
Status: CLOSED DUPLICATE of bug 450790
Product: Fedora
Classification: Fedora
Component: glib2 (Show other bugs)
powerpc Linux
medium Severity high
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
Depends On:
Blocks: 446014 447349
  Show dependency treegraph
Reported: 2008-06-04 01:07 EDT by Lubomir Rintel
Modified: 2008-06-12 04:04 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-06-12 04:04:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Lubomir Rintel 2008-06-04 01:07:31 EDT
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:

Backtrace from Epiphany:
Comment 1 David Woodhouse 2008-06-12 04:04:59 EDT
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

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.