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): inkscape-0.46-2.fc9.ppc How reproducible: Always Steps to Reproduce: 1.Start Inkscape 2.??? 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: inkscape-0.46-2.fc9.ppc [alex@localhost Movies]$
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.