GObject removal branch
2013/7/31 Markus Engel <p637777@...1081...>:
However, using it would require you to rewrite the init functions of all
SPObjects. ...
Replacing GObject-style initialization with constructor / destructor
shims in the style of NRObject would considerably simplify removing the GObject dependency later and reduce the burden of maintaining the init / dispose functions.
Well, please don't do that, I'm already done removing the GObject dependency, take a look at my branch at https://code.launchpad.net/~engelmarkus/inkscape/cppify .
Some review comments about this branch
1. The code seems wrong in a several places. For example, the constructor of SPObject retains the manual constructor calls and its destructor retains the manual destructor calls. Member initialization is already done before the constructor is even entered, and member destruction happens automatically after the destructor returns. I'm fairly sure this will lead to problems at runtime.
2. A lot of the constructor code should be changed to member initializers. See e.g. the constructor of SPItem.
3. Class names such as CSomething are reminiscent of MFC. The prefixes should be removed and the classes put in namespace Inkscape::SVG (since they represent objects in the SVG).
4. "#pragma once" is not used in existing Inkscape code. For consistency you should use standard include guards.
5. singleton.h should be merged into sp-factory.h. Singletons should be avoided where possible, so a separate singleton header is not a good idea. Boost doesn't have a singleton header for the same reason.
6. Method and variable names are not consistent with our coding style, though this could be addressed later since it's a leftover of previous GObject code. http://staging.inkscape.org/en/develop/coding-style/ http://inkscape.org/doc/coding_style.php (old website)
7. The virtual methods should be made protected, since they are not intended for use outside of SP node implementations.
Since the initialization rework I proposed would address points 1 and 2, it seems that this part of the work is actually not done.
What do others think? Should we work from Markus' code or rewrite the initialization first? Should we release 0.49 before introducing this kind of changes?
Regards, Krzysztof
On Wed, Jul 31, 2013 at 10:17 AM, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
What do others think? Should we work from Markus' code or rewrite the initialization first? Should we release 0.49 before introducing this kind of changes?
Speaking purely from the perspective of whether to wait for after 0.49 based on blocker bugs and available libraries... I really have to ask, why wait?
Our blocker list is still somewhat held hostage by the cairo/pixman situation. I believe two blockers have been fixed since the issue was last brought up. If there were less than 5 blockers, and stable releases of both cairo and pixman with what we need were out, I would be inclined to say let's not merge any more refactoring changes. Until either of those criteria are met, I'm personally pretty open as long as people don't outright break trunk. This is a seriously large gap between releases and if we can get as many changes in as possible, it seems more worthwhile (I really want it to feel that way to our users).
Just my .02
Cheers, Josh
First of all, thanks for your comments :) .
- The code seems wrong in a several places. For example, the constructor of SPObject retains the manual constructor calls and its destructor retains the manual destructor calls. Member initialization is already done before the constructor is even entered, and member destruction happens automatically after the destructor returns. I'm fairly sure this will lead to problems at runtime.
I didn't see them, I thought I fixed that everywhere...
- A lot of the constructor code should be changed to member initializers. See e.g. the constructor of SPItem.
I agree.
- "#pragma once" is not used in existing Inkscape code. For consistency you should use standard include guards.
Okay.
- singleton.h should be merged into sp-factory.h. Singletons should be avoided where possible, so a separate singleton header is not a good idea. Boost doesn't have a singleton header for the same reason.
I just did that as I noticed there are some other classes that use a singleton pattern as well, e. g. DocumentMetadata.
- Class names such as CSomething are reminiscent of MFC. The prefixes should be removed and the classes put in namespace Inkscape::SVG (since they represent objects in the SVG).
- Method and variable names are not consistent with our coding style, though this could be addressed later since it's a leftover of previous GObject code.
http://staging.inkscape.org/en/develop/coding-style/ http://inkscape.org/doc/coding_style.php (old website) I'll have a look.
- The virtual methods should be made protected, since they are not intended for use outside of SP node implementations.
Okay.
Regards, Markus
2013/7/31 Markus Engel <p637777@...1081...>:
- singleton.h should be merged into sp-factory.h. Singletons should be avoided where possible, so a separate singleton header is not a good idea. Boost doesn't have a singleton header for the same reason.
I just did that as I noticed there are some other classes that use a singleton pattern as well, e. g. DocumentMetadata.
Using a singleton is OK in the case of SPFactory, since I don't think there is any use in defining some other set of SPObject-constructing functions. The only issue I have here is that the content of singleton.h should be in sp-factory.h.
Regards, Krzysztof
Okay, I'll fix that now... I know that there is still some things left to do, e. g. turning some methods into member methods. But actually, I didn't notice any obvious bugs and keeping all the work in a separate branch gets quite difficult for me when there are so many people making changes to the files I modified. I will of course further refactor the classes I started with :) .
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Krzysztof Kosiński [mailto:tweenk.pl@...400...] Gesendet: Mittwoch, 31. Juli 2013 21:01 An: Markus Engel Cc: inkscape-devel@lists.sourceforge.net Betreff: Re: GObject removal branch
2013/7/31 Markus Engel <p637777@...1081...>:
- singleton.h should be merged into sp-factory.h. Singletons should be avoided where possible, so a separate singleton header is not a good idea. Boost doesn't have a singleton header for the same reason.
I just did that as I noticed there are some other classes that use a singleton pattern as well, e. g. DocumentMetadata.
Using a singleton is OK in the case of SPFactory, since I don't think there is any use in defining some other set of SPObject-constructing functions. The only issue I have here is that the content of singleton.h should be in sp-factory.h.
Regards, Krzysztof
On 31-7-2013 21:05, Markus Engel wrote:
Okay, I'll fix that now... I know that there is still some things left to do, e. g. turning some methods into member methods. But actually, I didn't notice any obvious bugs and keeping all the work in a separate branch gets quite difficult for me when there are so many people making changes to the files I modified. I will of course further refactor the classes I started with :) .
Yeah, refactoring in a branch for too long is nuts. I agree with Josh that it's fine to merge into trunk if you think it's ready. For you, I think the sooner the better.
Cheers, Johan
On 2013-07-31 21:05 +0200, Markus Engel wrote:
Okay, I'll fix that now... I know that there is still some things left to do, e. g. turning some methods into member methods. But actually, I didn't notice any obvious bugs and keeping all the work in a separate branch gets quite difficult for me when there are so many people making changes to the files I modified. I will of course further refactor the classes I started with :) .
JFYI - compiling your branch with Apple clang 3.1 on OS X 10.7.5 results in lots of warnings about mismatched tags (852 with r11718), for example:
In file included from ../../src/box3d.cpp:24: In file included from ../../src/box3d-context.h:20: ../../src/event-context.h:102:1: warning: 'SPEventContext' defined as a class here but previously declared as a struct [-Wmismatched-tags] class SPEventContext { ^ ../../src/event-context.h:26:1: note: did you mean class here? struct SPEventContext; ^~~~~~ class
Inkscape trunk used to have lots of these warnings too, once basic clang support was available - see comment #33 ff in https://bugs.launchpad.net/inkscape/+bug/992124
Attached is a list of the warnings (grepped for 'Wmismatched-tags').
Thanks. I hope I fixed most of them.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: suv@...2204... [mailto:suv@...2204...] Im Auftrag von su_v Gesendet: Mittwoch, 31. Juli 2013 22:20 An: Markus Engel Cc: 'Krzysztof Kosiński'; Inkscape Devel List Betreff: Re: [Inkscape-devel] GObject removal branch
On 2013-07-31 21:05 +0200, Markus Engel wrote:
Okay, I'll fix that now... I know that there is still some things left to do, e. g. turning some methods into member methods. But actually, I didn't notice any obvious bugs and keeping all the work in a separate branch gets quite difficult for me when there are so many people making changes to the files I modified. I will of course further refactor the classes I started with :) .
JFYI - compiling your branch with Apple clang 3.1 on OS X 10.7.5 results in lots of warnings about mismatched tags (852 with r11718), for example:
In file included from ../../src/box3d.cpp:24: In file included from ../../src/box3d-context.h:20: ../../src/event-context.h:102:1: warning: 'SPEventContext' defined as a class here but previously declared as a struct [-Wmismatched-tags] class SPEventContext { ^ ../../src/event-context.h:26:1: note: did you mean class here? struct SPEventContext; ^~~~~~ class
Inkscape trunk used to have lots of these warnings too, once basic clang support was available - see comment #33 ff in https://bugs.launchpad.net/inkscape/+bug/992124
Attached is a list of the warnings (grepped for 'Wmismatched-tags').
On 2013-07-31 22:54 +0200, Markus Engel wrote:
On 2013-07-31 22:20 +0200, su_v wrote:
JFYI - compiling your branch with Apple clang 3.1 on OS X 10.7.5 results in lots of warnings about mismatched tags (852 with r11718),
<…>
Inkscape trunk used to have lots of these warnings too, once basic clang support was available - see comment #33 ff in https://bugs.launchpad.net/inkscape/+bug/992124
Attached is a list of the warnings (grepped for 'Wmismatched-tags').
Thanks. I hope I fixed most of them.
- Warnings (compiler):
r11721 is down to 56 warnings about mismatched tags :) (new list attached - IIRC those about 'ColorProfile' originate from trunk)
- Warnings (runtime):
Testing the latest (clean) build with default (fresh) preferences, these warnings are printed to the console when opening 'Fill and Stroke', in addition to a couple of 'TypeNotRegistered' exceptions (see attached console log):
(inkscape:77083): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GObject'
(inkscape:77083): GLib-GObject-CRITICAL **: void g_object_set(gpointer, const gchar *, ...): assertion `G_IS_OBJECT (object)' failed
(inkscape:77083): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GObject'
(inkscape:77083): GLib-GObject-CRITICAL **: void g_object_set(gpointer, const gchar *, ...): assertion `G_IS_OBJECT (object)' failed
Note: the same critical warnings appear already at launch time if the preferences haven't been reset (preferences.xml removed) but have last been saved with a regular trunk build.
- Crash (not reproduced with current trunk builds):
1) launch inkscape (default prefs) 2) switch to the text tool (use keyboard shortcut 'T') (do not click on the canvas yet) 3) tap <space> once to switch tools (last used tool <-> select tool) 4) repeat step 3 a couple of times
-> crash:
GLib-GObject:ERROR:gsignal.c:634:void handler_unref_R(guint, gpointer, Handler *): assertion failed: (hlist->tail_before == handler)
Program received signal SIGABRT, Aborted. 0x00007fff93822ce2 in __pthread_kill () (gdb) bt #0 0x00007fff93822ce2 in __pthread_kill () #1 0x00007fff9b0297d2 in pthread_kill () #2 0x00007fff9b01aa7a in abort () #3 0x0000000102e82ff3 in g_assertion_message () #4 0x0000000102e83038 in g_assertion_message_expr () #5 0x0000000102e04456 in handler_unref_R () #6 0x0000000102e04c12 in signal_handlers_foreach_matched_R () #7 0x0000000102e04da8 in g_signal_handlers_disconnect_matched () #8 0x00000001015806b1 in gtk_im_multicontext_set_slave () #9 0x0000000101580c7c in gtk_im_multicontext_finalize () #10 0x0000000102df7a82 in g_object_unref () #11 0x00000001001a0f24 in SPTextContext::finish () #12 0x0000000100028c59 in SPDesktop::set_event_context2 () #13 0x00000001001ac3ce in tools_switch () #14 0x000000010005a3b9 in SPEventContext::root_handler () #15 0x00000001001a464a in SPTextContext::root_handler () #16 0x000000010005b3b6 in sp_event_context_virtual_root_handler () #17 0x000000010002f9b3 in sp_desktop_root_handler () #18 0x00000001002c1663 in sp_marshal_BOOLEAN__POINTER () #19 0x0000000102df2d7d in g_closure_invoke () #20 0x0000000102e05856 in signal_emit_unlocked_R () #21 0x0000000102e068cf in g_signal_emit_valist () #22 0x0000000102e06bca in g_signal_emit () #23 0x000000010021e31d in SPCanvasImpl::emitEvent () #24 0x0000000101595448 in _gtk_marshal_BOOLEAN__BOXED () #25 0x0000000102df2da0 in g_closure_invoke () #26 0x0000000102e05989 in signal_emit_unlocked_R () #27 0x0000000102e068cf in g_signal_emit_valist () #28 0x0000000102e06bca in g_signal_emit () #29 0x0000000101689d63 in gtk_widget_event_internal () #30 0x00000001016975df in gtk_window_propagate_key_event () #31 0x000000010169aecf in gtk_window_key_release_event () #32 0x0000000101595448 in _gtk_marshal_BOOLEAN__BOXED () #33 0x0000000102df2d7d in g_closure_invoke () #34 0x0000000102e05989 in signal_emit_unlocked_R () #35 0x0000000102e068cf in g_signal_emit_valist () #36 0x0000000102e06bca in g_signal_emit () #37 0x0000000101689d63 in gtk_widget_event_internal () #38 0x0000000101593733 in gtk_propagate_event () #39 0x00000001015933ef in gtk_main_do_event () #40 0x0000000101940a25 in gdk_event_dispatch () #41 0x0000000102e65867 in g_main_context_dispatch () #42 0x0000000102e65b75 in g_main_context_iterate () #43 0x0000000102e65dfa in g_main_loop_run () #44 0x0000000101592d74 in gtk_main () #45 0x0000000100002c2b in sp_main_gui () #46 0x0000000100001fa4 in start () (gdb)
- Warnings (compiler):
r11721 is down to 56 warnings about mismatched tags :) (new list attached - IIRC those about 'ColorProfile' originate from trunk)
Okay :) .
- Warnings (runtime):
Testing the latest (clean) build with default (fresh) preferences, these warnings are printed to the console when opening 'Fill and Stroke', in addition to a couple of 'TypeNotRegistered' exceptions > (see attached console log):
(inkscape:77083): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GObject'
(inkscape:77083): GLib-GObject-CRITICAL **: void g_object_set(gpointer, const gchar *, ...): assertion `G_IS_OBJECT (object)' failed
(inkscape:77083): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GObject'
(inkscape:77083): GLib-GObject-CRITICAL **: void g_object_set(gpointer, const gchar *, ...): assertion `G_IS_OBJECT (object)' failed
Note: the same critical warnings appear already at launch time if the preferences haven't been reset (preferences.xml removed) but have last been saved with a regular trunk build.
I asked about that a few weeks ago, but it seems I had forgotten about it. SPGuide used these GObject properties, I replaced them with normal ones... fixed, I hope :) . These TypeNotRegisteredExceptions are no problem, more of a hint that there is something wrong elsewhere. The old factory simply returns NULL when it didn't find a corresponding SP-class for an xml node. E. g. see SPObject::child_added (l. 577).
- Crash (not reproduced with current trunk builds):
I'm sorry, but I simply can't reproduce it :( . How often is "a couple of times"?
Regards, Markus
On 2013-08-01 14:36 +0200, Markus Engel wrote:
- Crash (not reproduced with current trunk builds):
I'm sorry, but I simply can't reproduce it :( . How often is "a couple of times"?
4-8 times
tested with builds using - GTK+/X11 2.24.20 - GTK+/X11 2.24.20+newer patches from gtk-2-24 git branch - GTK+/Quartz 2.24.20+newer patches from gtk-2-24 git branch (see Inkscape bug #1198597)
I can press space a hundred times, no matter whether fast or slowly, it won't crash :( . Does that happen with "D", too? Or with other tools? Are the warnings gone I hope?
Markus
-----Ursprüngliche Nachricht----- Von: suv@...2204... [mailto:suv@...2204...] Im Auftrag von su_v Gesendet: Donnerstag, 1. August 2013 17:03 An: Markus Engel Cc: 'Krzysztof Kosiński'; 'Inkscape Devel List' Betreff: Re: AW: [Inkscape-devel] GObject removal branch
On 2013-08-01 14:36 +0200, Markus Engel wrote:
- Crash (not reproduced with current trunk builds):
I'm sorry, but I simply can't reproduce it :( . How often is "a couple of times"?
4-8 times
tested with builds using - GTK+/X11 2.24.20 - GTK+/X11 2.24.20+newer patches from gtk-2-24 git branch - GTK+/Quartz 2.24.20+newer patches from gtk-2-24 git branch (see Inkscape bug #1198597)
On 2013-08-02 15:34 +0200, Markus Engel wrote:
I can press space a hundred times, no matter whether fast or slowly, it won't crash :( . Does that happen with "D", too? Or with other tools?
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:
Similar crash e.g. with the node tool:
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000040996cf0 0x0000000100a21478 in Inkscape::UI::TransformHandleSet::~TransformHandleSet (this=0x1409ab8f0) at ../../src/ui/tool/transform-handle-set.cpp:708 708 delete _handles[i]; (gdb) bt #0 0x0000000100a21478 in Inkscape::UI::TransformHandleSet::~TransformHandleSet (this=0x1409ab8f0) at ../../src/ui/tool/transform-handle-set.cpp:708 #1 0x0000000100a21415 in Inkscape::UI::TransformHandleSet::~TransformHandleSet (this=0x1409ab8f0) at ../../src/ui/tool/transform-handle-set.cpp:706 #2 0x0000000100a213b8 in Inkscape::UI::TransformHandleSet::~TransformHandleSet (this=0x1409ab8f0) at ../../src/ui/tool/transform-handle-set.cpp:706 #3 0x00000001009dcfe3 in Inkscape::UI::ControlPointSelection::~ControlPointSelection (this=0x14099cff0) at ../../src/ui/tool/control-point-selection.cpp:73 #4 0x00000001009dcf85 in Inkscape::UI::ControlPointSelection::~ControlPointSelection (this=0x14099cff0) at ../../src/ui/tool/control-point-selection.cpp:71 #5 0x00000001009dcf28 in Inkscape::UI::ControlPointSelection::~ControlPointSelection (this=0x14099cff0) at ../../src/ui/tool/control-point-selection.cpp:71 #6 0x0000000100a01356 in InkNodeTool::~InkNodeTool (this=0x10d569ca0) at ../../src/ui/tool/node-tool.cpp:175 #7 0x0000000100a01235 in InkNodeTool::~InkNodeTool (this=0x10d569ca0) at ../../src/ui/tool/node-tool.cpp:162 #8 0x0000000100a011d8 in InkNodeTool::~InkNodeTool (this=0x10d569ca0) at ../../src/ui/tool/node-tool.cpp:162 #9 0x000000010005abca in SPDesktop::set_event_context2 (this=0x10ad8fc00, toolName=@0x7fff5fbfdfb8) at ../../src/desktop.cpp:679 #10 0x00000001003599d4 in tools_switch (dt=0x10ad8fc00, num=1) at ../../src/tools-switch.cpp:125 #11 0x00000001000cb785 in sp_toggle_selector (dt=0x10ad8fc00) at ../../src/event-context.cpp:308 #12 0x00000001000cad89 in SPEventContext::root_handler (this=0x10d569ca0, event=0x1091c3d60) at ../../src/event-context.cpp:754 #13 0x0000000100a0440a in InkNodeTool::root_handler (this=0x10d569ca0, event=0x1091c3d60) at ../../src/ui/tool/node-tool.cpp:539 #14 0x00000001000ccce9 in sp_event_context_virtual_root_handler (event_context=0x10d569ca0, event=0x1091c3d60) at ../../src/event-context.cpp:1088 #15 0x00000001000cbd52 in sp_event_context_root_handler (event_context=0x10d569ca0, event=0x1091c3d60) at ../../src/event-context.cpp:1080 #16 0x000000010006d666 in sp_desktop_root_handler (event=0x1091c3d60, desktop=0x10ad8fc00) at ../../src/desktop-events.cpp:77 #17 0x00000001006456bf in sp_desktop_widget_event (widget=0x1082d3050, event=0x1091c3d60, dtw=0x1082b6030) at ../../src/widgets/desktop-widget.cpp:1013 #18 0x0000000103566fcf in _gtk_marshal_BOOLEAN__BOXED (closure=<value temporarily unavailable, due to optimizations>, return_value=0x7fff5fbfe958, n_param_values=<value temporarily unavailable, due to optimizations>, param_values=0x7fff5fbfea00, invocation_hint=<value temporarily unavailable, due to optimizations>, marshal_data=<value temporarily unavailable, due to optimizations>) at gtkmarshalers.c:86 #19 0x0000000106e3dbc4 in g_closure_invoke () #20 0x0000000106e4d5f9 in signal_emit_unlocked_R () #21 0x0000000106e4e7f8 in g_signal_emit_valist () #22 0x0000000106e4ed24 in g_signal_emit () #23 0x000000010367c08a in gtk_widget_event_internal (widget=0x1082d3050, event=0x1091c3d60) at gtkwidget.c:4905 #24 0x000000010368cc1a in gtk_window_propagate_key_event (window=0x1216d4e30, event=0x1091c3d60) at gtkwindow.c:5199 #25 0x0000000103690b48 in gtk_window_key_release_event (widget=0x1216d4e30, event=0x1091c3d60) at gtkwindow.c:5247 #26 0x0000000103566fcf in _gtk_marshal_BOOLEAN__BOXED (closure=<value temporarily unavailable, due to optimizations>, return_value=0x7fff5fbfeec8, n_param_values=<value temporarily unavailable, due to optimizations>, param_values=0x7fff5fbfef70, invocation_hint=<value temporarily unavailable, due to optimizations>, marshal_data=<value temporarily unavailable, due to optimizations>) at gtkmarshalers.c:86 #27 0x0000000106e3dbc4 in g_closure_invoke () #28 0x0000000106e4d83a in signal_emit_unlocked_R () #29 0x0000000106e4e7f8 in g_signal_emit_valist () #30 0x0000000106e4ed24 in g_signal_emit () #31 0x000000010367c24c in gtk_widget_event_internal (widget=0x1216d4e30, event=0x1091c3d60) at gtkwidget.c:5010 #32 0x0000000103565027 in gtk_propagate_event (widget=0x1216d4e30, event=<value temporarily unavailable, due to optimizations>) at gtkmain.c:2464 #33 0x0000000103564cce in gtk_main_do_event (event=<value temporarily unavailable, due to optimizations>) at gtkmain.c:1646 #34 0x0000000100005114 in snooper (event=0x1091c3d60) at ../../src/main.cpp:996 #35 0x0000000103a2f40a in gdk_event_dispatch (source=0x1091c3d60, callback=0, user_data=0x7625cf000000000) at gdkeventloop-quartz.c:677 #36 0x0000000106ec6838 in g_main_context_dispatch () #37 0x0000000106ec894e in g_main_context_iterate () #38 0x0000000106ec9eef in g_main_loop_run () #39 0x00000001035644f1 in gtk_main () at gtkmain.c:1257 #40 0x0000000100004864 in sp_main_gui (argc=1, argv=0x7fff5fbff788) at ../../src/main.cpp:1062 #41 0x000000010000405f in main (argc=1, argv=0x7fff5fbff788) at ../../src/main.cpp:786 (gdb)
The trigger to reproduce a crash when tool-switching between node and select tool seems possibly to be timing-related (somtimes, the faster I repeat tool switching by tapping the <space> bar, the more likely the crash occurs). Local trunk builds OTOH do not crash, no matter how fast (or slowly) I repeat the tool switch keyboard shortcut.
The backtrace above is from a different build of your branch on OS X, using older versions of GTK+/Quartz, glib and libsigc++ than the one from which I pasted the backtrace earlier: AFAICT, with the local builds of your branch, neither the compiler (Apple clang 3.1, Apple llvm-gcc-4.2) nor the backend of GTK+ (X11, Quartz) nor the versions of the dependencies seems to make a difference.
More backtraces from crashes with other tools (these don't seem to be consistently reproducible): https://www.dropbox.com/s/3bzeme1c9t5ui2w/branch-cppify-gdb-bt-tool-switch-crashes-osx-64bit.txt The backtraces in this file originate from three different builds (with varying backends/dependency versions).
Possibly these crashes are platform-specific (OS X) - unless someone with a linux build of your branch can reproduce similar issues with tool-switching, this is unlikely a blocker to merge your branch into trunk.
Are the warnings gone I hope?
Just two warnings left about mismatched tags at compile time:
../../src/extension/internal/cairo-render-context.h:32:1: warning: struct 'SPMask' was previously declared as a class [-Wmismatched-tags] ../../src/extension/internal/cairo-renderer.h:31:1: warning: struct 'SPMask' was previously declared as a class [-Wmismatched-tags]
The criticial Gtk warnings at launch (or when opening Fill&Stroke) are gone, yes.
2013/8/2 su_v <suv-sf@...58...>:
On 2013-08-02 15:34 +0200, Markus Engel wrote:
I can press space a hundred times, no matter whether fast or slowly, it won't crash :( . Does that happen with "D", too? Or with other tools?
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
participants (5)
-
Johan Engelen -
Josh Andler -
Krzysztof Kosiński -
Markus Engel -
su_v