Re: [Inkscape-devel] GObject removal branch
So far, only the crash with the text tool can be reproduced consistently (after 4 or at most ~8 times tapping the space bar).
However, with some patience I'm able to make your branch crash when tool-switching with other tools as well:
The backtrace looks like a double-free. There could be some leftover manual calls to member constructors / destructors in InkNodeTool >and SPTextContext.
Regards, Krzysztof
Hm, I didn't find any, but I'm sure this has got to do with the way I rewrote the part that switches the tools, see src/desktop.cpp:675. The old method is right underneath it, commented out. I reordered it, maybe this will help. Could you try it out once more? If you just comment out line 691 ("delete ec_old;"), does it still crash?
Regards, Markus
On Aug 2, 2013, at 1:37 PM, Markus Engel wrote:
So far, only the crash with the text tool can be reproduced consistently (after 4 or at most ~8 times tapping the space bar).
However, with some patience I'm able to make your branch crash when tool-switching with other tools as well:
The backtrace looks like a double-free. There could be some leftover manual calls to member constructors / destructors in InkNodeTool >and SPTextContext.
Regards, Krzysztof
Hm, I didn't find any, but I'm sure this has got to do with the way I rewrote the part that switches the tools, see src/desktop.cpp:675. The old method is right underneath it, commented out. I reordered it, maybe this will help. Could you try it out once more? If you just comment out line 691 ("delete ec_old;"), does it still crash?
*if* you can make it happen under Valgrind, that would probably the the fastest way to pinpoint it. Of course, running under valgrind does slow operation down significantly...
Otherwise if it is a double-free issue, you can often spot it by ensuring members are set to 0 after deleting. That will shift things to a null-pointer dereference which is a much more immediate crash and easily visible dump.
*if* you can make it happen under Valgrind, that would probably the the
fastest way to pinpoint it. Of course, running under valgrind >does slow operation down significantly...
Otherwise if it is a double-free issue, you can often spot it by ensuring
members are set to 0 after deleting. That will shift things to a null->pointer dereference which is a much more immediate crash and easily visible dump.
I think when toggling, the currently active tool simply deletes itself... Now I just have to figure out why this works in trunk. Regards, Markus
==4489== Invalid read of size 8 ==4489== at 0x4C5998: sp_event_context_virtual_root_handler(SPEventContext*, _GdkEvent*) (event-context.cpp:1092) ==4489== by 0x49778B: sp_desktop_root_handler(SPCanvasItem*, _GdkEvent*, SPDesktop*) (desktop-events.cpp:77) ==4489== by 0x6D3020: sp_marshal_BOOLEAN__POINTER (sp-marshal.cpp:124) ==4489== by 0x874A13F: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1) ==4489== by 0x875B54F: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1) ==4489== by 0x87630CA: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1) ==4489== by 0x8763641: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1) ==4489== by 0x66F087: SPCanvasImpl::emitEvent(SPCanvas*, _GdkEvent*) (sp-canvas.cpp:1591) ==4489== by 0x5C84598: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.13) ==4489== by 0x874A07D: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1) ==4489== by 0x875B2CF: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1) ==4489== by 0x87630CA: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1) ==4489== Address 0x1d1849e8 is 8 bytes inside a block of size 176 free'd ==4489== at 0x4C2A44B: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==4489== by 0x4922CB: SPDesktop::set_event_context2(std::string const&) (desktop.cpp:693) ==4489== by 0x60544B: tools_switch(SPDesktop*, int) (tools-switch.cpp:125) ==4489== by 0x4C78EA: SPEventContext::root_handler(_GdkEvent*) (event-context.cpp:310) ==4489== by 0x547F51: SPRectContext::root_handler(_GdkEvent*) (rect-context.cpp:383) ==4489== by 0x4C5990: sp_event_context_virtual_root_handler(SPEventContext*, _GdkEvent*) (event-context.cpp:1090) ==4489== by 0x49778B: sp_desktop_root_handler(SPCanvasItem*, _GdkEvent*, SPDesktop*) (desktop-events.cpp:77) ==4489== by 0x6D3020: sp_marshal_BOOLEAN__POINTER (sp-marshal.cpp:124) ==4489== by 0x874A13F: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1) ==4489== by 0x875B54F: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1) ==4489== by 0x87630CA: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1) ==4489== by 0x8763641: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1) ==4489== ==4489== Invalid write of size 1 ==4489== at 0x4C70BF: SPEventContext::root_handler(_GdkEvent*) (event-context.cpp:760) ==4489== by 0x54ECB6: SPSelectContext::root_handler(_GdkEvent*) (select-context.cpp:1224) ==4489== by 0x4C5990: sp_event_context_virtual_root_handler(SPEventContext*, _GdkEvent*) (event-context.cpp:1090) ==4489== by 0x49778B: sp_desktop_root_handler(SPCanvasItem*, _GdkEvent*, SPDesktop*) (desktop-events.cpp:77) ==4489== by 0x6D3020: sp_marshal_BOOLEAN__POINTER (sp-marshal.cpp:124) ==4489== by 0x874A13F: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1) ==4489== by 0x875B54F: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1) ==4489== by 0x87630CA: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1) ==4489== by 0x8763641: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1) ==4489== by 0x66F087: SPCanvasImpl::emitEvent(SPCanvas*, _GdkEvent*) (sp-canvas.cpp:1591) ==4489== by 0x5C84598: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.13) ==4489== by 0x874A07D: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1) ==4489== Address 0x1fcd4acc is 60 bytes inside a block of size 200 free'd ==4489== at 0x4C2A44B: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==4489== by 0x4922CB: SPDesktop::set_event_context2(std::string const&) (desktop.cpp:693) ==4489== by 0x60544B: tools_switch(SPDesktop*, int) (tools-switch.cpp:125) ==4489== by 0x4C75BB: SPEventContext::root_handler(_GdkEvent*) (event-context.cpp:303) ==4489== by 0x54ECB6: SPSelectContext::root_handler(_GdkEvent*) (select-context.cpp:1224) ==4489== by 0x4C5990: sp_event_context_virtual_root_handler(SPEventContext*, _GdkEvent*) (event-context.cpp:1090) ==4489== by 0x49778B: sp_desktop_root_handler(SPCanvasItem*, _GdkEvent*, SPDesktop*) (desktop-events.cpp:77) ==4489== by 0x6D3020: sp_marshal_BOOLEAN__POINTER (sp-marshal.cpp:124) ==4489== by 0x874A13F: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1) ==4489== by 0x875B54F: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1) ==4489== by 0x87630CA: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1) ==4489== by 0x8763641: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1) ==4489==
On 2013-08-02 22:37 +0200, Markus Engel wrote:
So far, only the crash with the text tool can be reproduced consistently (after 4 or at most ~8 times tapping the space bar).
However, with some patience I'm able to make your branch crash when tool-switching with other tools as well:
The backtrace looks like a double-free. There could be some leftover manual calls to member constructors / destructors in InkNodeTool >and SPTextContext.
Regards, Krzysztof
Hm, I didn't find any, but I'm sure this has got to do with the way I rewrote the part that switches the tools, see src/desktop.cpp:675. The old method is right underneath it, commented out. I reordered it, maybe this will help. Could you try it out once more?
Looks ok with GTK2 builds now: haven't been able to reproduce a crash with latest revision 11725 so far (I skipped building and testing r11724 separately).
Last night I also compiled your branch configured to use GTK3 (experimental) - these builds still can be triggered to crash on tool switch (mostly with the text tool). I'll upload some backtraces later tonight.
If you just comment out line 691 ("delete ec_old;"), does it still crash?
Haven't tested this yet because the GTK2-based builds no longer crash with r11725, but will try with the GTK3 builds tonight.
participants (3)
-
Jon Cruz -
Markus Engel -
su_v