Bug 447349

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
report.

Much thanks!

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

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
dialog.

ttyl
--Alex

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?

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
http://admin.fedoraproject.org/updates/F9/pending/glibc-2.8-7.

That glibc build fixes this issue for me as well.