Inkscape hangs; create rectangle, lock layer, select (root)
Can someone confirm the following issue?
I'm using Inkscape 0.41 (Feb 10 2005), installed via Debian package, in Debian with a dual-CPU Tyan motherboard.
I can reliably cause this hang by doing the following steps:
* launch Inkscape, and in the default new document, choose the rectangle tool and draw a rectangle
* with the rectangle still selected and its handles visible, click the "lock layer" icon on the status bar at the bottom of the window
* click the layer menu on the status bar next to the lock icon, and select "(root)"
At this point Inkscape hangs and begins to monopolize the CPU(s).
Thank you,
Steve D, New Mexico, US
I can reproduce using Inkscape CVS on Gentoo.
xscd wrote:
Can someone confirm the following issue?
I'm using Inkscape 0.41 (Feb 10 2005), installed via Debian package, in Debian with a dual-CPU Tyan motherboard.
I can reliably cause this hang by doing the following steps:
- launch Inkscape, and in the default new document, choose the rectangle
tool and draw a rectangle
- with the rectangle still selected and its handles visible, click the
"lock layer" icon on the status bar at the bottom of the window
- click the layer menu on the status bar next to the lock icon, and
select "(root)"
At this point Inkscape hangs and begins to monopolize the CPU(s).
Thank you,
Steve D, New Mexico, US
I got it, too, on current CVS. I ran it in GDB, and once the lockup started, I interupted it, and got this trace... hope it helps someone:
Program received signal SIGINT, Interrupt. 0x08275573 in sp_object_get_child_by_repr (object=0xa5e00b0, repr=0xb22549c) at sp-object.cpp:544 544 if ( SP_OBJECT_REPR(child) == repr ) { (gdb) bt #0 0x08275573 in sp_object_get_child_by_repr (object=0xa5e00b0, repr=0xb22549c) at sp-object.cpp:544 #1 0x0827793b in sp_object_child_added (object=0xa5e00b0, child=0xb22544c, ref=0xb22549c) at sp-object.cpp:559 #2 0x083946c7 in Inkscape::XML::SimpleNode::addChild (this=0xa5da640, child=0xb22544c, ref=0xb22549c) at xml/simple-node.cpp:259 #3 0x0838e11f in Inkscape::XML::SimpleNode::appendChild (this=0xb247cf8, child=0xa579d68) at simple-node.h:87 #4 0x083957ce in Inkscape::XML::SimpleNode::mergeFrom (this=0xa5da640, src=0xa5da67c, key=0x870e553 "id") at xml/simple-node.cpp:524 #5 0x08395797 in Inkscape::XML::SimpleNode::mergeFrom (this=0xa5da690, src=0xa5da6cc, key=0x870e553 "id") at xml/simple-node.cpp:516 #6 0x08395797 in Inkscape::XML::SimpleNode::mergeFrom (this=0xa5da6e0, src=0xa5da71c, key=0x870e553 "id") at xml/simple-node.cpp:516 #7 0x08395797 in Inkscape::XML::SimpleNode::mergeFrom (this=0xa5da730, src=0xa5da76c, key=0x870e553 "id") at xml/simple-node.cpp:516 #8 0x082f3e1f in sp_metadata_write (object=0xa5dfc00, repr=0xa5da76c, flags=2) at sp-metadata.cpp:185 #9 0x08275ddb in SPObject::updateRepr (this=0xa5dfc00, flags=186940664) at sp-object.cpp:920 #10 0x08268c1f in sp_group_write (object=0xa5db020, repr=0xa5da85c, flags=Variable "flags" is not available. ) at sp-item-group.cpp:300 #11 0x08283ba5 in sp_root_write (object=0xa5db020, repr=0xa5da85c, flags=Variable "flags" is not available. ) ---Type <return> to continue, or q <return> to quit---
xscd wrote:
Can someone confirm the following issue?
I'm using Inkscape 0.41 (Feb 10 2005), installed via Debian package, in Debian with a dual-CPU Tyan motherboard.
I can reliably cause this hang by doing the following steps:
- launch Inkscape, and in the default new document, choose the rectangle
tool and draw a rectangle
- with the rectangle still selected and its handles visible, click the
"lock layer" icon on the status bar at the bottom of the window
- click the layer menu on the status bar next to the lock icon, and
select "(root)"
At this point Inkscape hangs and begins to monopolize the CPU(s).
Thank you,
Steve D, New Mexico, US
Bob Jamison wrote:
I got it, too, on current CVS. I ran it in GDB, and once the lockup started, I interupted it, and got this trace... hope it helps someone:
Line 516 in xml/simple-node.cpp being called repeatedly looked suspicious, and I was thinking that maybe the fact that the rect is closed could be causing a recursive lockup. At line 516 in xml/simple-node.cpp, I added this line: printf("%lu %lu\n", (unsigned long)rch, (unsigned long)child);
...which printed these out before the lockup:
.... stuff..... 158672748 158779324 158672668 158779244 158943004 158943004 158943004 158943004 ...more stuff...
Note the duplicate lines.. I added a couple of lines to do a dupe check, converting the dupe to a NOP:
if (rch) { if (rch != child) { rch->mergeFrom(child, key); }
And now all seems well. Can someone test this out, and commit if you think it is ok? I need to leave the office now.
Bob
Quoting Bob Jamison <rjamison@...357...>:
Note the duplicate lines.. I added a couple of lines to do a dupe check, converting the dupe to a NOP:
if (rch) { if (rch != child) { rch->mergeFrom(child, key); }And now all seems well. Can someone test this out, and commit if you think it is ok? I need to leave the office now.
Uh, whoa. That should never ever happen. rch and child should be coming from separate subtrees, let alone never being the same.
This sounds like the XML tree is getting mangled somehow...
(I would have suspected this was the result of src == this, which you're not supposed to do, except that some of the earlier siblings were different)
-mental
On Fri, 11 Mar 2005 20:13:32 -0500, mental@...3... <mental@...3...> wrote:
Quoting Bob Jamison <rjamison@...357...>:
Note the duplicate lines.. I added a couple of lines to do a dupe check, converting the dupe to a NOP:
if (rch) { if (rch != child) { rch->mergeFrom(child, key); }And now all seems well. Can someone test this out, and commit if you think it is ok? I need to leave the office now.
Uh, whoa. That should never ever happen. rch and child should be coming from separate subtrees, let alone never being the same.
This sounds like the XML tree is getting mangled somehow...
(I would have suspected this was the result of src == this, which you're not supposed to do, except that some of the earlier siblings were different)
-mental
Just a note that the mergeFrom line is one I would have touched whule doing the janitor tasks. I can't comment further than that though because I'm not in a position right now to look at the code or my patches to check the conversion.
Cheers,
mental@...3... wrote:
Quoting Bob Jamison <rjamison@...357...>:
Note the duplicate lines.. I added a couple of lines to do a dupe check, converting the dupe to a NOP:
if (rch) { if (rch != child) { rch->mergeFrom(child, key); }And now all seems well. Can someone test this out, and commit if you think it is ok? I need to leave the office now.
Uh, whoa. That should never ever happen. rch and child should be coming from separate subtrees, let alone never being the same.
This sounds like the XML tree is getting mangled somehow...
(I would have suspected this was the result of src == this, which you're not supposed to do, except that some of the earlier siblings were different)
-mental
Yeah, it does seem to cure the symptom rather than the disease. However, it does also seem to be a valid safety check for a recursive method. But I'll leave it to whoever wrote the code. I'm still a bit foggy on it.
Bob
On Fri, 2005-03-11 at 23:32, Bob Jamison wrote:
Yeah, it does seem to cure the symptom rather than the disease. However, it does also seem to be a valid safety check for a recursive method. But I'll leave it to whoever wrote the code. I'm still a bit foggy on it.
(that would be me) I added an assert to mergeFrom itself, and discovered that the problem is that SPNamedView and SPMetadata's write functions don't deal properly with the case where the repr being written to is their own -- resulting in them attempting to merge a node with itself.
This should be fixed in CVS now.
-mental
participants (6)
-
unknown＠example.com -
Bob Jamison -
Jonathan Leighton -
MenTaLguY -
Robert Crosbie -
xscd