Red Hat Bugzilla – Bug 447349
Inkscape fails to start with "internal error"
Last modified: 2008-08-12 04:25:54 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.9b5) Gecko/2008043010 Fedora/3.0-0.60.beta5.fc9 Firefox/3.0b5
Description of problem:
When attempting to start Inkscape 0.46-2.fc9 on the PPC platform, program churns at 100% CPU for several seconds before presenting a dialog box labelled, "Inkscape encountered an internal error and will close now."
This problem does not occur on the i386 platform.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
3.Profit! (Not really, program dies a horrible death.)
Program stops starting.
We expect the program to finish starting... And then we expect to use it.
[alex@localhost Movies]$ inkscape
Emergency save activated!
Emergency save completed. Inkscape will close now.
If you can reproduce this crash, please file a bug at www.inkscape.org
with a detailed description of the steps leading to the crash, so we can fix it.
[alex@localhost Movies]$ inkscape --version
Inkscape 0.46 (Apr 5 2008)
[alex@localhost Movies]$ sudo rpm --query --all | grep -i inkscape
[sudo] password for alex:
Thanks for reporting this. I will have some trouble getting access to PPC
machine, therefore I'd very much appreciate if you could gather a stack trace of
the crashed process.
1.) Please install debugging symbols (you'll need yum-utils package):
# debuginfo-install inkscape
2.) Run inkscape from within gdb, and enable logging:
$ gdb inkscape
(gdb) set pagination off
(gdb) set confirm off
(gdb) set logging file inkscape.log
(gdb) set logging on
wait for the process to crash
(gdb) thread apply all backtrace
3.) Please attach the inkscape.log that was obtained in above step to this bug
The debugging symbols are pretty heavy. It wants to download some 230 MB of
data, so it'll be a few hours before I can send any useful backtraces.
Btw, I was just experimenting with running Inkscape in gdb, and its behavior
inside gdb changes markedly.
When running Inkscape inside gdb, it segfaults fairly quickly, and never
displays the "internal error" dialog. When running Inkscape outside of gdb, it
always displays the "internal error" dialog, and only sometimes segfaults AFTER
the dialog is closed. (Often it doesn't segfault at all, it just doesn't start.)
(Race conditions, anyone?)
I can wait until the dialog pops up, attach gdb to the running process, and get
a backtrace of that point. Or I can get a backtrace of the various segfaults.
Your choice. ;)
Created attachment 305989 [details]
Backtrace of Inksape crashing under GDB
Here's a very simple GDB session which includes a segmentation fault (before
any sort of "internal error" box or any other program output) and a backtrace.
Please let me know if you would also like backtraces of the point where
inkscape pops up the "internal error" dialog and/or segfaults after closing the
Alex: I think this is going to be enough for know. Other problems you have seen
are probably just other symptoms of this, from the smart crash handler that
inkscape hooks on SIGSEGV.
2285 continue_emission = accumulator->func (ihint, return_accu,
I am wondering what is the value of "accumulator", could you please do "print
accumulator" in gdb?
Created attachment 306000 [details]
"accumulator" seems to be NULL
Here you can see me trying to print out the value of "accumulator". I've never
seen that "value optimized out" message before, but I think I sufficiently
demonstrate that accumulator is NULL at the time of the crash.
I have had the exact same bug running Fedora 9 PPC. I got a copy of the
inkscape-0.46 source, did a standard configure, and compiled it.
Unsurprisingly, inkscape died with the same "Internal Error." The default
configure settings use -O2, and so a first step, I reconfigured with
CFLAGS="-O0" and CXXFLAGS="-O0" and recompiled. This corrected the "Internal
Error" problem. From my testing so far, Inkscape has not had any other problems.
I also tried to build the most recent "stable" inkscape tarball and had similar
difficulties. (I was planning on digging farther, but life happened...)
If -O0 fixes the symptoms, are we looking at a compiler bug?
*** Bug 448302 has been marked as a duplicate of this bug. ***
Bugs #446014, #448307 and #448306 all document another PowerPC crasher issue. These bugs affect
epiphany, yelp and devhelper. All of these applications use xulrunner and inkscape does not. However, I
thought there still might be some relation.
Mike: Epiphany (bug #446014) indeed traces back to the very same place, NULL
dereference after propagation of realize signal. I am specially thankful for
your finding, since given my knowledge of gsignal and glib you probably saved me
substantial amount of time :)
I'll clone this for Glib, and let's see if they will be of any help.
This is fixed for me by the new glibc package at
That glibc build fixes this issue for me as well.