Hello, I found that this small change prevents a startup crash on OS X 10.3.9 (also added to https://bugs.launchpad.net/inkscape/+bug/185689):
--- inkscape.trunk/src/sp-filter.cpp.orig Sat Dec 22 12:15:36 2007 +++ inkscape.trunk/src/sp-filter.cpp.noStartupCrash Sat Feb 2 08:55:03 2008 @@ -110,7 +110,7 @@ sp_filter_init(SPFilter *filter)
filter->_renderer = NULL;
- filter->_image_name = map<gchar *, int, ltstr>(); + filter->_image_name.clear();
filter->filterRes = NumberOptNumber();
While I'm happy that Inkscape can actually run, it's not obvious to me why this fixes the crash, nor if this is generaly an acceptable thing to do. Could someone possibly test that this does not cause a problem on another platform?
By the way, after applying this patch, I have another crash in sp-filter.cpp when opening "Help->About Inkscape", so I wonder if there's either a std::map problem with gcc 3.3 or memory is getting trashed. Random theories welcome :-).
Thanks!, John
Sat, 2 Feb 2008 09:11:51 -0800 "John Faith" <jfaith7@...400...> kirjoitti:
I found that this small change prevents a startup crash on OS X 10.3.9 (also added to https://bugs.launchpad.net/inkscape/+bug/185689):
--- inkscape.trunk/src/sp-filter.cpp.orig Sat Dec 22 12:15:36 2007 +++ inkscape.trunk/src/sp-filter.cpp.noStartupCrash Sat Feb 2 08:55:03 2008 @@ -110,7 +110,7 @@ sp_filter_init(SPFilter *filter)
filter->_renderer = NULL;
- filter->_image_name = map<gchar *, int, ltstr>();
filter->_image_name.clear();
filter->filterRes = NumberOptNumber();
While I'm happy that Inkscape can actually run, it's not obvious to me why this fixes the crash, nor if this is generaly an acceptable thing to do. Could someone possibly test that this does not cause a problem on another platform?
By the way, after applying this patch, I have another crash in sp-filter.cpp when opening "Help->About Inkscape", so I wonder if there's either a std::map problem with gcc 3.3 or memory is getting trashed. Random theories welcome :-).
That was one of the most annoying bugs I've ever had to debug. SPFilter is not an actual C++ class, so it's not constructed. This means, that filter->_image_name is not construced either. Before that line you changed, filter->_image_name has rubbish state and that line is trying to set it to sensible state.
So... That line should just call the constructor for filter->_image_name. I can see, how my original version may be compiled as 'construct a temporary map and use operator= to copy it to filter->_image_name'.
participants (2)
-
John Faith
-
Niko Kiirala