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"
Created attachment 45482 [details] strace output of running inkscape Attached strace output, hope it helps.
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)
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
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.
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 ()
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.
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.
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.
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.
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
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).
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.
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.
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.
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
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.
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.
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.
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).
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
Confirmed. The culprit was libsigc++, which apparently didn't get rebuilt after gcc update. Should we resolve this bug as FIXED or INVALID?
Great! Perhaps the bug should be filed on libsigc++ instead?
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.
Sorry for the spam, following up at Bug 79058 for anyone interested.
