Bug 447349 - Inkscape fails to start with "internal error"
Inkscape fails to start with "internal error"
Product: Fedora
Classification: Fedora
Component: inkscape (Show other bugs)
powerpc Linux
low Severity high
: ---
: ---
Assigned To: Lubomir Rintel
Fedora Extras Quality Assurance
: 448302 (view as bug list)
Depends On: 449883
  Show dependency treegraph
Reported: 2008-05-19 12:31 EDT by Alex Markley
Modified: 2008-08-12 04:25 EDT (History)
6 users (show)

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

Attachments (Terms of Use)
Backtrace of Inksape crashing under GDB (6.17 KB, text/plain)
2008-05-19 14:26 EDT, Alex Markley
no flags Details
"accumulator" seems to be NULL (1.47 KB, text/plain)
2008-05-19 15:29 EDT, Alex Markley
no flags Details

  None (edit)
Description Alex Markley 2008-05-19 12:31:23 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):

How reproducible:

Steps to Reproduce:
1.Start Inkscape
3.Profit! (Not really, program dies a horrible death.)

Actual Results:
Program stops starting.

Expected Results:
We expect the program to finish starting... And then we expect to use it.

Additional info:
[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]$ 
[alex@localhost Movies]$ 
[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: 
[alex@localhost Movies]$
Comment 1 Lubomir Rintel 2008-05-19 13:49:39 EDT
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
(gdb) run
wait for the process to crash
(gdb) thread apply all backtrace
(gdb) quit

3.) Please attach the inkscape.log that was obtained in above step to this bug

Much thanks!
Comment 2 Alex Markley 2008-05-19 14:10:47 EDT
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. ;)

Thanks, ttyl
Comment 3 Alex Markley 2008-05-19 14:26:01 EDT
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

Comment 4 Lubomir Rintel 2008-05-19 15:13:03 EDT
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,
handler_return, accumulator->data);

I am wondering what is the value of "accumulator", could you please do "print
accumulator" in gdb?
Comment 5 Alex Markley 2008-05-19 15:29:41 EDT
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.
Comment 6 Elliot Paquette 2008-05-26 14:10:09 EDT
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.
Comment 7 Alex Markley 2008-05-26 22:03:14 EDT
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?
Comment 8 Ian Weller 2008-05-27 00:45:32 EDT
*** Bug 448302 has been marked as a duplicate of this bug. ***
Comment 9 W. Michael Petullo 2008-06-03 20:13:57 EDT
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. 
Comment 10 Lubomir Rintel 2008-06-04 01:00:21 EDT
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.
Comment 11 W. Michael Petullo 2008-07-09 19:03:41 EDT
This is fixed for me by the new glibc package at
Comment 12 Alex Markley 2008-07-09 21:10:01 EDT
That glibc build fixes this issue for me as well.

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