Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 73743 - inkscape 0.40 crashes immediately
Summary: inkscape 0.40 crashes immediately
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Marc Hildebrand (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-12-07 18:54 UTC by Mark R. Pariente
Modified: 2005-01-22 01:49 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
strace output of running inkscape (inkscape-0.40-strace.txt,155.71 KB, text/plain)
2004-12-07 18:57 UTC, Mark R. Pariente
Details
backtrace for the crash (inkscape-0.40-backtrace.txt,1.53 KB, text/plain)
2004-12-08 22:29 UTC, Mark R. Pariente
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark R. Pariente 2004-12-07 18:54:39 UTC
Just emerge'd inkscape 0.40, trying to run it results with:

$ inkscape
*** glibc detected *** free(): invalid pointer: 0x0838c460 ***

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.

and is a no go. Using glibc with NPTL (not nptlonly though), could this be the culprit?

Reproducible: Always
Steps to Reproduce:
1. run inkscape 0.40
2.
3.

Actual Results:  
crashes

Expected Results:  
runs

Portage 2.0.51-r8 (default-linux/x86/2004.2, gcc-3.4.3, glibc-2.3.4.20041102-r0,
2.6.9-gentoo i686)
=================================================================
System uname: 2.6.9-gentoo i686 Intel(R) Pentium(R) M processor 2.00GHz
Gentoo Base System version 1.6.7
Python:              dev-lang/python-2.3.4 [2.3.4 (#1, Aug 21 2004, 11:02:59)]
dev-lang/python:     2.3.4
sys-devel/autoconf:  2.59-r6, 2.13
sys-devel/automake:  1.8.5-r2, 1.5, 1.4_p6, 1.6.3, 1.7.9, 1.9.3
sys-devel/binutils:  2.15.92.0.2-r1
sys-devel/libtool:   1.5.2-r7
virtual/os-headers:  2.6.8.1-r1
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer -mfpmath=sse -mmmx -msse2"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config
/usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/
/usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/
/usr/share/texmf/xdvi/ /var/qmail/control"CONFIG_PROTECT_MASK="/etc/gconf
/etc/terminfo /etc/env.d"
CXXFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer -mfpmath=sse -mmmx -msse2"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms"
GENTOO_MIRRORS="ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/
http://gentoo.mirrors.pair.com/ http://gentoo.osuosl.org/
http://ftp-mirror.internap.com/pub/gentoo/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X acpi alsa apm artworkextra avi berkdb bitmap-fonts cdr crypt cups dvd
dvdr eds encode esd evo f77 fam flac foomaticdb fortran gdbm gif gnome gpm
gstreamer gtk gtk2 hal imagemagick imap imlib java jpeg ldap libg++ libwww mad
mikmod mmx motif mozilla mpeg ncurses nls nntp nptl oggvorbis opengl oss pam
pdflib perl png python quicktime readline samba sdl slang spell sse ssl svga
tcltk tcpd tetex tiff truetype x86 xine xml2 xmms xv zlib"
Comment 1 Mark R. Pariente 2004-12-07 18:57:00 UTC
Created attachment 45482 [details]
strace output of running inkscape

Attached strace output, hope it helps.
Comment 2 Bryce Harrington 2004-12-08 22:01:33 UTC
Can you post a gdb backtrace on this one?

Note - I'm running Inkscape on Gentoo and have never seen this behavior, however it has been reported by others so is probably a legitimate bug.

-- Bryce (bryce@bryceharrington.com)
Comment 3 Bryce Harrington 2004-12-08 22:12:28 UTC
I notice that the crash seems to start right after loading the 'gimpgrad' extension (which allows importing Gimp gradients into Inkscape).  This is a new extension and differs from others in that it hooks into a loadable library.  Additional discussion about this is on the Inkscape development mailing list here:

http://sourceforge.net/mailarchive/forum.php?thread_id=6091850&forum_id=36054

Can you try deleting the 'gimpgrad.inx' file from your Inkscape extensions directory (which would be in /usr/share/inkscape/extensions/ or similar), and see if that resolves the issue?

Bryce
Comment 4 Mark R. Pariente 2004-12-08 22:29:37 UTC
Created attachment 45583 [details]
backtrace for the crash

Ok, backtrace attached. I did compile inkscape with debug symbols, but seems
the failure happens somewhere else.
Comment 5 Mark R. Pariente 2004-12-08 22:31:33 UTC
Deleted gimpgrad.inx, now have an infinite loop (won't start, won't print any crash messages) Backtrace:

#0  0x080ca098 in sp_document_add_resource ()
#1  0x080f80e8 in SPGroup::setLayerMode ()
#2  0x08107730 in sp_object_read_attr ()
#3  0x080f648a in sp_group_get_type ()
#4  0x08109d11 in sp_object_invoke_build ()
#5  0x0810a127 in sp_object_invoke_build ()
#6  0x081170cb in sp_root_get_type ()
#7  0x08109d11 in sp_object_invoke_build ()
#8  0x08105d75 in sp_object_repr_build_tree ()
#9  0x080c669c in SPDocument::collectOrphans ()
#10 0x080c6d6d in sp_document_new ()
#11 0x080ca98f in sp_file_new ()
#12 0x080caa8b in sp_file_new_default ()
#13 0x080c6133 in sp_main_gui ()
#14 0x080c62c5 in main ()
Comment 6 Robert Davis 2004-12-22 08:49:32 UTC
Was having a similar problem but different backtrace (mine was sending garbage loading icons from icons.svg).  Lowered my CFLAGS to my base CFLAGS and recompiled glibmm, gtkmm, and inkscape and works now.
Comment 7 Mark R. Pariente 2004-12-27 22:52:32 UTC
Tried the same here, only to find out that I can't even compile glibmm! Not even with empty CFLAGS, getting weird stuff, might be related to this bug perhaps:

../../glib/glibmm/.libs/libglibmm-2.4.so: undefined reference to `sigc::internal::signal_impl::insert(std::_List_iterator<sigc::slot_base>, sigc::slot_base const&)'
../../glib/glibmm/.libs/libglibmm-2.4.so: undefined reference to `sigc::internal::signal_impl::erase(std::_List_iterator<sigc::slot_base>)'
collect2: ld returned 1 exit status

All this with gcc 3.4.3. gcc 3.3.4 has compiled glibmm-2.4.4 fine. Also emerged gtkmm and inkscape with gcc 3.3.4 (and empty CFLAGS) and now inkscape works.
Comment 8 Bryce Harrington 2005-01-18 22:29:24 UTC
I've been fussing with this bug for a while now but cannot
recreate it on Gentoo with the emerged inkscape 0.40.  Are
others seeing this same problem?  

We're expecting to get 0.41 released within a month or so,
and I would really be frustrated if we could not get Gentoo
to accept 0.41 as stable.  0.37 is oooollllldddd and has a 
ton of bugs that have been fixed since.  So any help to gain
closure on this bug would be highly appreciated.
Comment 9 Christoph Brill (egore) (RESIGNED) 2005-01-18 22:39:37 UTC
I have 2 (more or less) similar systems. Both are running on ~x86 and have inkscape 0.40 installed. On the one system it simply failes with the error shown here. On the other system it runs without any issues. The first system (on which it doesn't run) has been on ~x86 for quite a long time and also using bmg and gentoo-de overlays (which causes gnome to be 2.9 based). The other system was (until a week ago) mostly x86 and inkscape runs fine. I'm currently updating the system and see if inkscape will still run, because I think it's a dependecy of inkscape that causes this error and not inkscape itself.
Comment 10 Bryce Harrington 2005-01-18 22:45:09 UTC
Awesome - can you identify the differences between the two systems?
I'd love to see this bug narrowed down.

Could I also trouble you to try compiling 0.41CVS on the system that
fails?  It would be useful to know if the problem that existed in 
0.40 has since been fixed.

Bryce
Comment 11 Christoph Brill (egore) (RESIGNED) 2005-01-18 23:05:44 UTC
I will try to figure out what is different between the 2 systems (it should not be much difference, but I think the bmg overlays might have introduced some)

Also I will compile 0.41CVS later today (in about 10 hours) and see if it works (I'm at work now and don't have access to my box).
Comment 12 Bryce Harrington 2005-01-18 23:19:16 UTC
Thanks.  It would be excellent if we could solve this bug.
Most other distros are running much more recent versions
of Inkscape, so it's a bit embarrassing for all of us that 
Gentoo is stuck with an ancient 0.37 version.
Comment 13 Mark R. Pariente 2005-01-18 23:41:53 UTC
I actually have inkscape 0.40 up and running. Been quite a while since I did it, sorry for not following up in the bug report. As far as I can remember, I did just as comment #6 advised, recompiled glibmm, gtkmm and inkscape (not sure if I did that with lower CFLAGS though) and it runs now without problem. I can give this set (glibmm+gtkmm+inkscape) another spin with the same flags tomorrow, will post the result. Hope this helps.
Comment 14 Mark R. Pariente 2005-01-18 23:48:30 UTC
Damn, sorry about this, not even reading my own comments on the bug :-(. The solution was to recompile glibmm, gtkmm and inkscape with gcc 3.3.4. The problem seems to be gcc 3.4.3. I will give the whole thing another spin tomorrow anyway, since the compiler has been updated to 3.4.3.20050110.
Comment 15 Christoph Brill (egore) (RESIGNED) 2005-01-19 11:44:35 UTC
Additional info:

- I emerged gtkmm on one of my systems with gcc 3.4.3, inkscape still works
- I was unable to emerge glibmm using gcc 3.4.3
- inkscape CVS builds but does not start, fails with:
egore@egore912 ~ $ inkscape 

** (inkscape:19135): WARNING **: Modules directory (/usr/local/share/inkscape/extensions) is unavailable.  External modules in that directory will not be loaded.
** (inkscape:19135): WARNING **: failed to load icon 'sticky_zoom'
** (inkscape:19135): WARNING **: failed to load icon 'visible'
** (inkscape:19135): WARNING **: failed to load icon 'hidden'
** (inkscape:19135): WARNING **: failed to load icon 'lock_unlocked'
** (inkscape:19135): WARNING **: failed to load icon 'width_height_lock'

and than I'm hanging in console and no window appears
Comment 16 Bryce Harrington 2005-01-19 12:07:31 UTC
Okay thanks.  Since you seem to have tracked this down to 
gcc 3.4.3 and gtkmm rather than Inkscape, can this bug be
closed?

Btw, those warnings you're seeing are normal if you've not
run 'make install' before executing a newly compiled Inkscape.
They do not cause a hang or other problem (just a few buttons
won't have their images).

The hang is probably related to the gtkmm issue.  You can bang
on it in gdb if you want to see where it's getting stuck, but
my guess is that it's just due to the compiler issues you found.

Comment 17 Marc Hildebrand (RETIRED) gentoo-dev 2005-01-19 12:10:14 UTC
Hi folks.
I tried to reproduce this crash but no way.
Today, I emerged inkscape on my laptop with gcc-3.4.3-r1

     Wed Jan 19 09:54:53 2005 --> dev-cpp/glibmm-2.4.4 
     Wed Jan 19 10:03:26 2005 --> dev-cpp/gtkmm-2.4.8 
     Wed Jan 19 10:11:57 2005 --> media-gfx/inkscape-0.40 

Inkscape seems to work well and runs stable. The installation is x86 with no "~" apart from xorg, gcc and inkscape with it's deps.

I'm about to mark this one stable as soon as possible. There are two other bugs to be resolved before this can happen, though.

What about tihs one here, do we agree that we can mark it WORKSFORME or WONTFIX?

Cheers,

Marc.
Comment 18 Bryce Harrington 2005-01-19 12:36:56 UTC
Yes, there had been similar issues reported to inkscape
about compiling with gcc; to my knowledge, these were generally
resolved through either changing gcc versions or recompiling
underlying libraries.  I heard something about the gcc project
changing the way C++ binding works (presumably as of 3.4.3), 
which would explain some of the funky behaviors people have run
into.  

If this hypothesis is correct, then users who have upgraded gcc
to this version might spot similar build issues in other C++
apps that have changed more frequently than gtkmm/glibmm.  

Anyway, I'd still like to hear more reports of build problems,
but it sounds like this one is not really an inkscape-specific
issue, but rather an issue with upgrading gcc and linking
C++ libraries and C++ code compiled with different versions of
gcc.  It makes sense that we'd see these issues most prevalently
with gentoo since by definition use of gentoo requires recompilation
of things.  Possibly, if the hypothesis above is correct, this 
suggests that emerging gcc through versions that involve C++ 
linking style changes should force a recompilation of ALL C++
libraries installed on the system, before any other apps get
built.



Comment 19 Mark R. Pariente 2005-01-19 19:10:08 UTC
I am afraid not. I had inkscape up and running (glibmm, gtkmm and inkscape compiled with gcc 3.3.4), and a new version showed up (inkscape-0.40-r1), and I compiled it (only inkscape) with gcc 3.4.3, and I am having this bug again :( This might as well be due to the mentioned inconsistency of c++ stuff compiled with different versions of gcc, but I think we should be more careful in moving inkscape to stable. For starters, glibmm doesn't even build with gcc 3.4.3, and running a mixed configuration (glibmm and gtkmm built with 3.3.4, inkscape built with 3.4.3) doesn't work either. 

So, I think the best solution would be to make glibmm 2.4.4 and inkscape 0.40 block on gcc 3.4.3 (since glibmm doesn't even compile and inkscape/3.4.3 doesn't play well with glibmm+gtkmm/3.3.4).
Comment 20 arossiach 2005-01-21 04:20:09 UTC
Well, Fixed for me with : 
emerge libsigc++ 
emerge glibmm
with gcc 3.4.3
related with bug http://bugs.gentoo.org/show_bug.cgi?id=55268
Comment 21 Mark R. Pariente 2005-01-21 23:15:37 UTC
Confirmed. The culprit was libsigc++, which apparently didn't get rebuilt after gcc update. Should we resolve this bug as FIXED or INVALID?
Comment 22 Bryce Harrington 2005-01-21 23:25:43 UTC
Great!

Perhaps the bug should be filed on libsigc++ instead?

Comment 23 Mark R. Pariente 2005-01-22 01:35:30 UTC
Ok, resolving this bug. It is probably a good idea to file a libsigc++ bug though, I think I am not the only one to upgrade gcc regularly using emerge world :) At the very least, the gcc ebuild should prompt the user to re-emerge libsigc++ if portage isn't doing it.
Comment 24 Mark R. Pariente 2005-01-22 01:49:10 UTC
Sorry for the spam, following up at Bug 79058 for anyone interested.