- launch
- open any file from gui (file>open or file>open recent)
- press ctrl+shift+F
crashes with:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1087741248 (LWP 19098)] IA__g_hash_table_destroy (hash_table=0x989fd20) at ghash.c:742 742 node = node->next; Current language: auto; currently c (gdb) bt #0 IA__g_hash_table_destroy (hash_table=0x989fd20) at ghash.c:742 #1 0x080d610a in ~SPDocument (this=0x8409fc0) at document.cpp:118 #2 0x40ae8ec4 in GC_invoke_finalizers () at finalize.c:787 #3 0x40ae8fb9 in GC_notify_or_invoke_finalizers () at finalize.c:844 #4 0x40aea3bd in GC_generic_malloc (lb=7, k=2) at malloc.c:188 #5 0x40aeb37a in GC_malloc_uncollectable (lb=7) at mallocx.c:572 #6 0x082bd37f in Inkscape::GC::Anchored::_new_anchor (this=0x9827e04) at gc-core.h:88 #7 0x0820e16a in NRArenaItem (this=0x9827e00) at gc-anchored.h:51 #8 0x08216ee2 in NRObject::invoke_ctor<NRArenaShape> (object=0x9827e00) at nr-object.h:75 #9 0x082568cd in NRObject::alloc (type=141831864) at libnr/nr-object.cpp:181 #10 0x08116a40 in sp_shape_show (item=0x92e7208, arena=0x989fd20, key=35, flags=1) at nr-object.h:114 #11 0x081017a1 in sp_item_invoke_show (item=0x92e7208, arena=0x863ef90, key=35, flags=1) at sp-item.cpp:697 #12 0x080fdb0c in sp_group_show (item=0x92e7208, arena=0x863ef90, key=35, flags=1) at sp-item-group.cpp:410 #13 0x08103d43 in sp_marker_show_instance (marker=0x9011b6c, parent=0x87f4200, key=160039424, pos=0, base=@0xbfffe240, linewidth=1.70000005) at sp-marker.cpp:581 #14 0x081160fa in sp_shape_update_marker_view (shape=0x86a22f8, ai=0x87f4200) at sp-shape.cpp:555 #15 0x08116eb0 in sp_shape_update (object=0x86a22f8, ctx=0xbfffe3c0, flags=4) at sp-shape.cpp:278 #16 0x08108e76 in SPObject::updateDisplay (this=0x86a22f8, ctx=0xbfffe3c0, flags=4) at sp-object.cpp:1016 #17 0x080fca30 in sp_group_update (object=0x86a22f8, ctx=0xbfffe520, flags=4) at sp-item-group.cpp:240 #18 0x08108e76 in SPObject::updateDisplay (this=0x867417c, ctx=0xbfffe520, flags=4) at sp-object.cpp:1016 #19 0x080fca30 in sp_group_update (object=0x867417c, ctx=0xbfffe700, flags=4) at sp-item-group.cpp:240 #20 0x08115058 in sp_root_update (object=0x843e6c0, ctx=0x83511b0, flags=3) at sp-root.cpp:559 #21 0x08108e76 in SPObject::updateDisplay (this=0x843e6c0, ctx=0xbfffe810, flags=3) at sp-object.cpp:1016 #22 0x080d54aa in sp_document_ensure_up_to_date (doc=0x8409f18) at document.cpp:577 #23 0x081a819e in sp_marker_list_from_doc (m=0x92f6fb8, current_doc=0x98a0200, source=0x8409ea8, markers_doc=0x0, sandbox=0x8409f18, menu_id=0x82ca5ff "marker-mid") at dialogs/stroke-style.cpp:841 #24 0x081a8a31 in ink_marker_menu (tbl=0x989fd20, menu_id=0x82ca5ff "marker-mid", sandbox=0x8409f18) at dialogs/stroke-style.cpp:1104 #25 0x081abb6e in sp_stroke_style_line_widget_new () at dialogs/stroke-style.cpp:1515 #26 0x081a32da in sp_object_properties_dialog () at dialogs/object-properties.cpp:178 #27 0x0822aa01 in sp_action_perform (action=0x845c330, data=0x0) at helper/action.cpp:135
On Sun, 2005-02-13 at 10:43, bulia byak wrote:
launch
open any file from gui (file>open or file>open recent)
press ctrl+shift+F
It's probably not breakage of fill and stroke per se; this would be bound to happen eventually when anything triggered a garbage collection ... looks like priv->iddef is corrupt for some reason, and the SPDocument destructor is blowing up as a result.
I wonder which SPDocument would be getting garbage-collected, though? Can you set a breakpoint in SPDocument::~SPDocument and check the uri?
If it's the document currently being worked on, that's obviously wrong, and it's likely a refcounting bug, as SPDocument is protected against premature garbage collection by refcounts.
-mental
On Sun, 13 Feb 2005 11:14:54 -0500, MenTaLguY <mental@...3...> wrote:
I wonder which SPDocument would be getting garbage-collected, though? Can you set a breakpoint in SPDocument::~SPDocument and check the uri?
When I open fill&stroke without loading any document (no crash), ~SPDocument is not called. When I do it after loading something, then _after_ I press ctrl+shift+f but before the crash, it destroys the empty document (uri == NULL, base == NULL, name == "New document 1") that was created on launch and then replaced by the loaded one. I don't know why this destroying happens not when the empty document is really killed, but when I run fill&stroke after that.
I won't be able to do any debugging until later today because right now I will roll back to yesterday's CVS in order to finish a design.
Quoting bulia byak <buliabyak@...400...>:
When I open fill&stroke without loading any document (no crash), ~SPDocument is not called. When I do it after loading something, then _after_ I press ctrl+shift+f but before the crash, it destroys the empty document (uri == NULL, base == NULL, name == "New document 1") that was created on launch and then replaced by the loaded one.
Ahh, ok. This makes sense to me now. I was worried it was something exotic.
I don't know why this destroying happens not when the empty document is really killed, but when I run fill&stroke after that.
It's because SPDocument is now managed by the collector, and there object destruction happens non-deterministically[1]. It just happens that running fill and stroke usually triggers a garbage collection pass (and therefore destruction of the lingering SPDocument) for you.
Now, that doesn't explain why SPDocument's destructor crashes, which is the real problem. Probably I screwed up SPDocument's initialization/finalization logic when I re-munged it into the new framework, or it's possible that the code getting called in a different context has exposed an existing bug. I'll look into it more tonight as I have time.
Long-term, we do still want to minimize the use of automatic finalizers as much as possible[2].
-mental
[1] From the point of view of an application programmer, anyway. This isn't special to libgc, but a behavior common to most automatic garbage collectors. A Java programmer (hi Jon!) will be familiar with this kind of thing.
[2] This is also considered best practice in languages like Java; there are well-developed techniques for doing this.
This is still not fixed.
Another breakage which is likely caused either by Mental's or Bryce's changes: launch, draw anything, press Ctrl+Q. It silently quits instead of asking for save.
Please fix this ASAP.
I'm with bulia on this one.. its really urgent
On Mon, 14 Feb 2005 21:04:45 -0400, bulia byak <buliabyak@...400...> wrote:
This is still not fixed.
Another breakage which is likely caused either by Mental's or Bryce's changes: launch, draw anything, press Ctrl+Q. It silently quits instead of asking for save.
Please fix this ASAP.
SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, 2005-02-15 at 05:40, Andy Fitzsimon wrote:
I'm with bulia on this one.. its really urgent
What do you think I'm working on? I only just fixed the crash bug (which turned out to be a stray assignment that I ought to have gotten rid of originally).
Until tonight though I kind of need to focus on my paying job instead...
-mental
FYI, I've filed this as bug 1123610 and assigned it to myself.
The correct fix is going to require some thought; it's at least partly an old architectural issue that has been dredged up.
-mental
participants (4)
-
unknown＠example.com -
Andy Fitzsimon -
bulia byak -
MenTaLguY