Hello,
I've been having the same problem for quite some time; the CVS version compiles but then it doesn't run. It just hogs the cpu and nothing happens and I have to kill it. Stable version works fine. There seem to be no error messages during compilation. I've tried several times, latest was a few hours ago. If you'd like any kind of information about my system libraries etc, just ask. I'm on gentoo linux.
I'd like to solve this!
Thanks,
Johan Forsberg
On Tue, 26 Oct 2004, Johan Forsberg wrote:
Hello,
I've been having the same problem for quite some time; the CVS version compiles but then it doesn't run. It just hogs the cpu and nothing happens and I have to kill it. Stable version works fine. There seem to be no error messages during compilation. I've tried several times, latest was a few hours ago. If you'd like any kind of information about my system libraries etc, just ask. I'm on gentoo linux.
I'd like to solve this!
Hi Johan,
I'm on gentoo as well, but have never seen that particular issue.
One thing you could try is running it through gdb and see what it's actually doing while it's hogging the cpu. Do:
$ gdb src/inkscape
then give the command 'run'. Let it go until it's hogging the cpu as usual, then ctrl-Z it. Within gdb, pull up a backtrace:
(gdb) bt
Sometimes it'll show you the function its stuck in, and you can guess what's going on by the filename. You can restart it again via
(gdb) continue
Start/stop it a few times to get a feel for what's going on. Let us know what you see.
Also, have you run make install? It's possible that it's looking for its icons or something. Note that by default it will install Inkscape to /usr/local/bin, so it won't overwrite your current binary.
Bryce
On 2004-10-26 04:43, Bryce Harrington wrote:
On Tue, 26 Oct 2004, Johan Forsberg wrote:
Hello,
I've been having the same problem for quite some time; the CVS version compiles but then it doesn't run. It just hogs the cpu and nothing happens and I have to kill it. Stable version works fine. There seem to be no error messages during compilation. I've tried several times, latest was a few hours ago. If you'd like any kind of information about my system libraries etc, just ask. I'm on gentoo linux.
I'd like to solve this!
Hi,
I've experienced exactly the same thing. I tried everything, removing the ~/.inkscape-dir, make distclean, --disable-mmx, changing boehm, gtk and gtkmm version, nothing solved it.
Then I changed gcc version to 3.3.4 (i compiled with 3.4.2 before), and that did it for me. (i'm on slackware, but that's probably not the issue).
[snip]
One thing you could try is running it through gdb and see what it's actually doing while it's hogging the cpu. Do:
[snip]
Start/stop it a few times to get a feel for what's going on. Let us know what you see.
I did try this... and from what I can remember, the result was very different from time to time. My debugging skills are pretty weak, so i didn't manage to draw any conclusion from the result. I'll compile it with 3.4.2 again, and post the gdb-results here, or create a new bug in the tracker...
/Gustav
On Tue, 2004-10-26 at 19:32, Gustav Broberg wrote:
I did try this... and from what I can remember, the result was very different from time to time. My debugging skills are pretty weak, so i didn't manage to draw any conclusion from the result. I'll compile it with 3.4.2 again, and post the gdb-results here, or create a new bug in the tracker...
Please do both.
What would be particularly helpful in narrowing down where it's stuck would be to run it from gdb, then control+C, print a backtrace, and resume again several times.
The parts in common between the backtraces should give us a pretty good idea of where the issue is manifesting itself; we can perform a more in-depth analysis from there.
-mental
On 2004-10-27 02:42, MenTaLguY wrote:
On Tue, 2004-10-26 at 19:32, Gustav Broberg wrote:
I did try this... and from what I can remember, the result was very different from time to time. My debugging skills are pretty weak, so i didn't manage to draw any conclusion from the result. I'll compile it with 3.4.2 again, and post the gdb-results here, or create a new bug in the tracker...
Please do both.
What would be particularly helpful in narrowing down where it's stuck would be to run it from gdb, then control+C, print a backtrace, and resume again several times.
Okey, now I've recompiled with GCC 3.4.2, without optimize and with extra debugging info. Inkscape seems to get stuck at exactly same place every time, not at different locations from time to time, like I rembered it.
As far as I can see, some functions in signal.h, slot_base.h (from sigc++) and stl_list.h, are called, over and over again. It looks it this happens when icons.svg is loaded on startup, and sp_gradient_build is called.
I've filed a report here:
https://sourceforge.net/tracker/index.php?func=detail&aid=1055034&gr...
That should narrow it down a bit. Hope it helps!
/Gustav
On Wed, 27 Oct 2004, Gustav Broberg wrote:
I've experienced exactly the same thing. I tried everything, removing the ~/.inkscape-dir, make distclean, --disable-mmx, changing boehm, gtk and gtkmm version, nothing solved it.
Then I changed gcc version to 3.3.4 (i compiled with 3.4.2 before), and that did it for me. (i'm on slackware, but that's probably not the issue).
Aha! It was starting to feel like a build issue. On my gentoo system I'm using version 3.3.3.
I did try this... and from what I can remember, the result was very different from time to time. My debugging skills are pretty weak, so i didn't manage to draw any conclusion from the result. I'll compile it with 3.4.2 again, and post the gdb-results here, or create a new bug in the tracker...
Hmm, almost sounds like at some point the execution is jumping to a random location in the code. That's often a symptom of referencing an undefined pointer or of having a bad address in there.
Since gcc 3.4.2 is pretty bleeding edge, it's possible there's a bug in it. Can you try 3.4.1 or 3.4.0 and see if the bug occurs with those versions too? It may also be valuable to read through the gcc bug list and/or post-3.4.2 changelog to see if others encountered similar problems.
Bryce
On Wed, 27 Oct 2004 01:32:24 +0200, Gustav Broberg <broberg@...370...> wrote:
Hi,
I've experienced exactly the same thing. I tried everything, removing the ~/.inkscape-dir, make distclean, --disable-mmx, changing boehm, gtk and gtkmm version, nothing solved it.
Then I changed gcc version to 3.3.4 (i compiled with 3.4.2 before), and that did it for me. (i'm on slackware, but that's probably not the issue).
I've been using 3.4.1 too! I tried compiling with 3.3.1 and it just crashes directly on startup, before the window has even opened. This is what i get from "gdb inkscape":
------------------- (gdb) run Starting program: /usr/local/bin/inkscape warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. [New Thread 16384 (LWP 4797)]
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 4797)] 0x78657400 in ?? () ------------------
I'm confused now! :)
[snip]
One thing you could try is running it through gdb and see what it's actually doing while it's hogging the cpu. Do:
[snip]
Start/stop it a few times to get a feel for what's going on. Let us know what you see.
I did try this... and from what I can remember, the result was very different from time to time. My debugging skills are pretty weak, so i didn't manage to draw any conclusion from the result. I'll compile it with 3.4.2 again, and post the gdb-results here, or create a new bug in the tracker...
On Wed, 27 Oct 2004, Johan Forsberg wrote:
On Wed, 27 Oct 2004 01:32:24 +0200, Gustav Broberg <broberg@...370...> wrote:
I've experienced exactly the same thing. I tried everything, removing the ~/.inkscape-dir, make distclean, --disable-mmx, changing boehm, gtk and gtkmm version, nothing solved it.
Then I changed gcc version to 3.3.4 (i compiled with 3.4.2 before), and that did it for me. (i'm on slackware, but that's probably not the issue).
I've been using 3.4.1 too! I tried compiling with 3.3.1 and it just crashes directly on startup, before the window has even opened. This is what i get from "gdb inkscape":
(gdb) run Starting program: /usr/local/bin/inkscape warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. [New Thread 16384 (LWP 4797)]
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 4797)] 0x78657400 in ?? ()
I'm confused now! :)
Did you do a 'make clean' before rebuilding it?
Bryce
On 2004-10-26 04:26, Johan Forsberg wrote:
Hello,
I've been having the same problem for quite some time; the CVS version compiles but then it doesn't run. It just hogs the cpu and nothing happens and I have to kill it. Stable version works fine. There seem to be no error messages during compilation. I've tried several times, latest was a few hours ago. If you'd like any kind of information about my system libraries etc, just ask. I'm on gentoo linux.
I'd like to solve this!
Now I've got it working! I upgraded sigc++ to version 2.0.6 and now it executes normally. Reading from: http://cvs.gnome.org/viewcvs/libsigc++2/NEWS?rev=1.21
"2.0.6 ----- * Fixed compilation for gcc-3.4."
So, I guess it makes sense. More of a sigc issue than an inkscape issue then, right? Maybe the configuration could check if sigc++ >= 2.0.6 when gcc >= 3.4.0?
/Gustav
Gustav Broberg wrote:
So, I guess it makes sense. More of a sigc issue than an inkscape issue then, right? Maybe the configuration could check if sigc++ >= 2.0.6 when gcc >= 3.4.0?
Or sigc++ <= 2.0.3
2.0.6 only came out just now. For my builds here I had to step down from 2.0.5 and 2.0.4 to 2.0.3 to get things to work.
On Wed, 27 Oct 2004, Gustav Broberg wrote:
Now I've got it working! I upgraded sigc++ to version 2.0.6 and now it executes normally. Reading from: http://cvs.gnome.org/viewcvs/libsigc++2/NEWS?rev=1.21
"2.0.6
- Fixed compilation for gcc-3.4."
So, I guess it makes sense. More of a sigc issue than an inkscape issue then, right? Maybe the configuration could check if sigc++ >= 2.0.6 when gcc >= 3.4.0?
Aha! Sounds like an interplay between gcc and libsigc++.
If you're comfortable tweaking autoconf, yeah definitely send in a patch for that. In any case, could you and Johan update the CompilingInkscape page in Wiki to add this note, in case others run into the same issue? I'm betting that once gcc 3.4 gets out into the wild we'll see this issue crop up more.
Bryce
Bryce Harrington wrote:
Aha! Sounds like an interplay between gcc and libsigc++.
If you're comfortable tweaking autoconf, yeah definitely send in a patch for that. In any case, could you and Johan update the CompilingInkscape page in Wiki to add this note, in case others run into the same issue? I'm betting that once gcc 3.4 gets out into the wild we'll see this issue crop up more.
Bryce
Yeah. But some care should be taken. Like Jon, I too had problems with Gtkmm2.4.5 disagreeing with libsigc++2.0.5. I guess 2.0.6 must address the problems.
Bob
On Wed, 27 Oct 2004 13:11:53 +0200, Gustav Broberg <broberg@...370...> wrote:
On 2004-10-26 04:26, Johan Forsberg wrote:
Hello,
I've been having the same problem for quite some time; the CVS version compiles but then it doesn't run. It just hogs the cpu and nothing happens and I have to kill it. Stable version works fine. There seem to be no error messages during compilation. I've tried several times, latest was a few hours ago. If you'd like any kind of information about my system libraries etc, just ask. I'm on gentoo linux.
I'd like to solve this!
Now I've got it working! I upgraded sigc++ to version 2.0.6 and now it executes normally. Reading from: http://cvs.gnome.org/viewcvs/libsigc++2/NEWS?rev=1.21
"2.0.6
- Fixed compilation for gcc-3.4."
So, I guess it makes sense. More of a sigc issue than an inkscape issue then, right? Maybe the configuration could check if sigc++ >= 2.0.6 when gcc >= 3.4.0?
I updated to 2.0.6 (also had to rebuild glibmm and gtkmm) and tried again, now it doesn't hang anymore, it just crashes on startup :P This is what gdb says:
----------------- (gdb) run Starting program: /usr/local/bin/inkscape warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. [New Thread 16384 (LWP 16376)]
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 16376)] 0x40534f2d in std::locale::operator=(std::locale const&) () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/libstdc++.so.5 (gdb) bt #0 0x40534f2d in std::locale::operator=(std::locale const&) () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/libstdc++.so.5 #1 0x4052dcbb in std::ios_base::_M_init() () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/libstdc++.so.5 #2 0x4052bf2b in std::basic_ios<char, std::char_traits<char>
::init(std::basic_streambuf<char, std::char_traits<char> >*) ()
from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/libstdc++.so.5 #3 0x4055ebcf in std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char>
::basic_ostringstream(std::_Ios_Openmode) ()
from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/libstdc++.so.5 #4 0x08242209 in Path::svg_dump_path() const (this=0x85f9c08) at stringstream.h:12 (gdb) -----------
It looks like it's using a gcc 3.3 libstdc++... I'm using gcc 3.4.2 all the way. But I'm not sure what this means. Anyway maybe this problem is unrelated to the libsigc++ one?
/Johan
On Thu, 28 Oct 2004, Johan Forsberg wrote:
I updated to 2.0.6 (also had to rebuild glibmm and gtkmm) and tried again, now it doesn't hang anymore, it just crashes on startup :P This is what gdb says:
(gdb) run Starting program: /usr/local/bin/inkscape
Program received signal SIGSEGV, Segmentation fault. 0x40534f2d in std::locale::operator=(std::locale const&) () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/libstdc++.so.5 (gdb) bt #0 0x40534f2d in std::locale::operator=(std::locale const&) () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/libstdc++.so.5 #1 0x4052dcbb in std::ios_base::_M_init() () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/libstdc++.so.5 #2 0x4052bf2b in std::basic_ios<char, std::char_traits<char>
::init(std::basic_streambuf<char, std::char_traits<char> >*) ()
from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/libstdc++.so.5 #3 0x4055ebcf in std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char>
::basic_ostringstream(std::_Ios_Openmode) ()
from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/libstdc++.so.5 #4 0x08242209 in Path::svg_dump_path() const (this=0x85f9c08) at stringstream.h:12 (gdb)
It looks like it's using a gcc 3.3 libstdc++... I'm using gcc 3.4.2 all the way. But I'm not sure what this means. Anyway maybe this problem is unrelated to the libsigc++ one?
No, this is definitely libstdc++ related - you can see it listed in each of the call lines above. None of the listed calls refer to Inkscape functions (which typically are prepended with sp_).
So keep checking your libraries and if things are compiled correctly. For instance, do you need to recompile libsigc or other libs that you installed since your gcc upgrade?
Bryce
On 2004-10-28 02:45, Johan Forsberg wrote:
On Wed, 27 Oct 2004 13:11:53 +0200, Gustav Broberg <broberg@...370...> wrote:
On 2004-10-26 04:26, Johan Forsberg wrote:
Hello,
I've been having the same problem for quite some time; the CVS version compiles but then it doesn't run. It just hogs the cpu and nothing happens and I have to kill it. Stable version works fine. There seem to be no error messages during compilation. I've tried several times, latest was a few hours ago. If you'd like any kind of information about my system libraries etc, just ask. I'm on gentoo linux.
I'd like to solve this!
Now I've got it working! I upgraded sigc++ to version 2.0.6 and now it executes normally. Reading from: http://cvs.gnome.org/viewcvs/libsigc++2/NEWS?rev=1.21
"2.0.6
- Fixed compilation for gcc-3.4."
So, I guess it makes sense. More of a sigc issue than an inkscape issue then, right? Maybe the configuration could check if sigc++ >= 2.0.6 when gcc >= 3.4.0?
I updated to 2.0.6 (also had to rebuild glibmm and gtkmm) and tried again, now it doesn't hang anymore, it just crashes on startup :P
Yeah, I had to rebuild glibmm too. Then I got some strange segfaults, not exactly the same as yours, but nothing obvious. The solution, for me, was to then rebuild Inkscape from scratch (i.e make distclean, and build with gcc 3.4).
So, did you rebuild Inkscape after the libsigc++2-update?
/Gustav
participants (6)
-
Bob Jamison -
Bryce Harrington -
Gustav Broberg -
Johan Forsberg -
Jon A. Cruz -
MenTaLguY