Since valgrind isn't an option in mingw I gave Dr. Memory a try. With both Trunk and Inkscape 0.48.2 it catches a ton of memory errors and exits before the first window even opens. Here is the first thing it sees (wrong) in 0.48.2
As you can see it isn't able to figure out where in inkscape.exe the problem was, but presumably compiling it with -g
would fix that. In this case there the g_win32_locale_filename_from_utf8 is only ever called from main.cpp and script.cpp, my guess is that one of those is with a NULL name passed in.
Later on some of the errors become quite mysterious - this one is in the same thread (they all were) but doesn't list inkscape.exe at all.
Since valgrind isn't an option in mingw I gave Dr. Memory a try. With both Trunk and Inkscape 0.48.2 it catches a ton of memory errors and exits before the first window even opens. Here is the first thing it sees (wrong) in 0.48.2
Error #1: UNINITIALIZED READ: reading register al 2.0-0.dll! g_array_ sized_new 2.0-0.dll! g_array_ new 2.0-0.dll! g_static_ private_ set 2.0-0.dll! g_get_charset 2.0-0.dll! g_locale_ from_utf8 2.0-0.dll! g_win32_ locale_ filename_ from_utf8 exe+0x50ab> ) exe+0x10db> ) exe+0x1158> ) dll!RegisterWai tForInputIdle
# 0 libglib-
# 1 libglib-
# 2 libglib-
# 3 libglib-
# 4 libglib-
# 5 libglib-
# 6 inkscape.exe!? +0x0 (0x004050ab <inkscape.
# 7 inkscape.exe!? +0x0 (0x004010db <inkscape.
# 8 inkscape.exe!? +0x0 (0x00401158 <inkscape.
# 9 KERNEL32.
Note: @0:00:14.891 in thread 3616
Note: instruction: test %al %al
As you can see it isn't able to figure out where in inkscape.exe the problem was, but presumably compiling it with -g locale_ filename_ from_utf8 is only ever called from main.cpp and script.cpp, my guess is that one of those is with a NULL name passed in.
would fix that. In this case there the g_win32_
Later on some of the errors become quite mysterious - this one is in the same thread (they all were) but doesn't list inkscape.exe at all.
Error #8: UNINITIALIZED READ: reading 0x0022fa98- 0x0022fa9c 4 byte(s) dll!RegDeleteVa lueW +0xf5 (0x77ddeee6 <ADVAPI32. dll+0xeee6> ) dll!WSCEnumProt ocols +0xa63 (0x71ab85c5 <WS2_32. dll+0x85c5> ) dll!WSCEnumProt ocols +0x9a1 (0x71ab8503 <WS2_32. dll+0x8503> ) dll!WSCEnumProt ocols +0x839 (0x71ab839b <WS2_32. dll+0x839b> ) dll!WSCEnumProt ocols +0x75b (0x71ab82bd <WS2_32. dll+0x82bd> ) dll!WSCEnumProt ocols +0x43d (0x71ab7f9f <WS2_32. dll+0x7f9f> ) dll!WSCEnumProt ocols +0x34d (0x71ab7eaf <WS2_32. dll+0x7eaf> ) 2.0-0.dll! _g_networking_ init 2.0-0.dll! g_inet_ address_ get_type 2.4-1.dll! ZN3Gio9wrap_ initEv 2.4-1.dll! ZN3Gio4initEv 2.4-1.dll! ZN3Gtk4Main20in it_gtkmm_ internalsEv
# 0 ADVAPI32.
# 1 WS2_32.
# 2 WS2_32.
# 3 WS2_32.
# 4 WS2_32.
# 5 WS2_32.
# 6 WS2_32.
# 7 libgio-
# 8 libgio-
# 9 libgiomm-
#10 libgiomm-
#11 libgtkmm-
Note: @0:00:21.562 in thread 3016
Note: instruction: cmp %ecx (%eax)
Anyway, if any of these messages are real then this tool may be helpful in finding the memory problems under windows.