Empty application window on startup on OS X 10.3.9

[John Faith]

In svn version 16780, when the application is started by double-clicking on Inkscape.app, only a small empty X11 window is displayed. There is no main application window with menus, etc.

It seems that there may be a path issue in packaging/macosx/Resources/script. Making this change allows the main window to come up:

 BASE="`echo "$0" | sed -e 's/\/Contents\/Resources\/script/\//'`"
 cd "$BASE"
-exec "$CWD/bin/inkscape" "$@"
+cd Contents/Resources/bin
+exec "./inkscape" "$@"

, but I'm not sure if this is an issue on other OS X versions, so this fix may not be generally applicable.

[John Faith (jfaith7)]

Apparently this is a crash which happens when icons are loaded, which must be why messing up the path in the startup script allows the application to stay running (icon loading fails more gracefully).

The crash and backtrace from gdb:
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x00586440 in std::_Rb_tree<char*, std::pair<char* const, int>, std::_Select1st<std::pair<char* const, int> >, ltstr, std::allocator<std::pair<char* const, int> > >::operator=(std::_Rb_tree<char*, std::pair<char* const, int>, std::_Select1st<std::pair<char* const, int> >, ltstr, std::allocator<std::pair<char* const, int> > > const&) () at /opt/local/include/gtkmm-2.4/gtkmm/papersize.h:37
37 const Glib::ustring PAPER_NAME_A3 = "iso_a3";
(gdb) bt
#0 0x00586440 in std::_Rb_tree<char*, std::pair<char* const, int>, std::_Select1st<std::pair<char* const, int> >, ltstr, std::allocator<std::pair<char* const, int> > >::operator=(std::_Rb_tree<char*, std::pair<char* const, int>, std::_Select1st<std::pair<char* const, int> >, ltstr, std::allocator<std::pair<char* const, int> > > const&) () at /opt/local/include/gtkmm-2.4/gtkmm/papersize.h:37
#1 0x00088584 in sp_filter_init(SPFilter*) () at libnr/nr-point-matrix-ops.h:11
#2 0x0147c998 in g_type_create_instance ()
#3 0x0146b044 in g_object_constructor ()
#4 0x01466a60 in g_object_newv ()
#5 0x01466eb8 in g_object_new_valist ()
#6 0x01466784 in g_object_new ()
#7 0x00021928 in sp_object_build(SPObject*, SPDocument*, Inkscape::XML::Node*) (object=0x78a6b78, document=0x3aefee0, repr=0x7ac9288) at sp-object.cpp:792
#8 0x00021cb8 in sp_object_invoke_build(SPObject*, SPDocument*, Inkscape::XML::Node*, unsigned) (object=0x7a3ff70, document=0x78a6b78, repr=0x3aefee0, cloned=128750216) at sp-object.cpp:852
#9 0x00021974 in sp_object_build(SPObject*, SPDocument*, Inkscape::XML::Node*) (object=0x15cd260, document=0x3aefee0, repr=0x78a6b78) at sp-object.cpp:795
#10 0x00015b74 in sp_root_build(SPObject*, SPDocument*, Inkscape::XML::Node*) () at libnr/nr-maybe.h:75
#11 0x00021cb8 in sp_object_invoke_build(SPObject*, SPDocument*, Inkscape::XML::Node*, unsigned) (object=0x15cd260, document=0x3aefee0, repr=0x3aefee0, cloned=114630624) at sp-object.cpp:852
#12 0x0001b484 in sp_object_repr_build_tree(SPDocument*, Inkscape::XML::Node*) () at libnr/nr-maybe.h:75
#13 0x0000c910 in sp_document_create(Inkscape::XML::Document*, char const*, char const*, char const*, unsigned) (rdoc=<incomplete type>, uri=0x8153560 "Contents/Resources/icons/icons.svg", base=0x8153950 "Contents/Resources/icons/", name=0x8154f20 "icons.svg", keepalive=0) at document.cpp:291
#14 0x0000d210 in sp_document_new(char const*, unsigned, bool) (uri=0x8153560 "Contents/Resources/icons/icons.svg", keepalive=0, make_new=false) at document.cpp:464
#15 0x0024e8f8 in load_svg_pixels(char const*, unsigned, unsigned) (name=0x8110100 "fill_and_stroke", lsize=0, psize=16) at widgets/icon.cpp:802
#16 0x0024ca64 in sp_icon_fetch_pixbuf(SPIcon*) (icon=0x7003b88) at widgets/icon.cpp:867
#17 0x0047c244 in ink_action_create_menu_item(_GtkAction*) () at libnr/nr-object.h:118
#18 0x031f5c54 in gtk_action_create_menu_item ()
#19 0x031f4e4c in gtk_action_create_menu_...

[John Faith (jfaith7)]

A bit more info about the crash: printing "filter->_image_name._M_t._M_header" in gdb shows that it is NULL which explains why the app would crash, but it's not known why this is NULL.

The attached patch seems to fix this crash, though it's not clear why. The same std::map construct "map<gchar *, int, ltstr>()" used in a small test program on OS X 10.3.9/gcc 3.3 seems to work fine, so it may be something else which is causing a problem in the map (memory corruption??).

With the attached patch the application can start, but the "Help->About Inkscape" option causes a crash, also in sp-filter.cpp. Differnt bug?

[Bryce Harrington (bryce)]

jiho, could you take a look at this? I'm guessing this is just a transitory packaging issue?

[JiHO (jiho)]

The path change in the patch above causes Inkscape to start from a different directory and the application hence doesn't find its resources, among them its icons. Since the crash is caused by the icons, this seems to fix the crash, but the underlying cause is still there.
However John seems to have worked it out and discussed this on the list. I asked for SVN access for him since he's done more than enough to "earn" it and since it will make things much easier for him. Especially now that I've very little time. It must be frustrating to work things out and to never see them committed because the guy in charge has something else to do :(
Go John! Go! :)

[John Faith (jfaith7)]

The previous, one-line patch should be ignored.

Changing the struct SPFilter member _image_name from a std::map to a pointer to a std::map and allocating the map in sp_filter_init() lets the map be initialized correctly.

Just a guess, but it seems that the g_type_create_instance() (in the original crash backtrace) might be allocating memory for the filter struct without calling the constructor for its member objects.

[Niko Kiirala (kiirala)]

Thank you for the patch. I've committed it in as SVN revision 17252.