On Fri, Nov 5, 2010 at 1:30 PM, Jong Bor Lee <jlee binarybag com> wrote:
I am developing a Gtk application using gtkmm on Windows Vista with Visual Studio 2005. The application works fine on the development machine but I have received crash reports after it has been run on Windows XP machines (both Service Pack 2 and 3). I distribute the app with the directory structure described in http://live.gnome.org/gtkmm/MSWindows and it had given me no problems so far.The crash gives no error messages except for Windows asking whether I want to report the error.In order to solve the problem, I tried to compile the program against different versions of gtkmm (a recent stable version gtkmm-win32-devel-2.16.0-4 and an older version gtkmm-win32-devel-2.10.11-1) but the problem persisted.I hunted down the problem to a call to window->create_cairo_context() inside the on_expose_event of a Gtk::DrawingArea. When I commented out this call, the problem would disappear. So I wrote the following minimal program, which still crashes:#include <gtkmm.h>class MyWindow : public Gtk::Window {bool on_expose_event(GdkEventExpose* event) {std::cout << "expose" << std::endl;Glib::RefPtr<Gdk::Window> window = get_window();if(window) {std::cout << "win" << std::endl;std::cout << "Get cairo" << std::endl;Cairo::RefPtr<Cairo::Context> cr = window->create_cairo_context();std::cout << "Get cairo done" << std::endl;} else {std::cout << "no win" << std::endl;}return true;}};int main (int argc, char *argv[]) {Gtk::Main m(argc,argv);MyWindow w;m.run(w);return 0;}This minimal app may run and display the window without problem, but if I move the window off the screen limits or if I minimize/maximize it enough times (thus triggering calls to on_expose_event), it will eventually crash. It may also be the case that it won't crash the first time, but it will crash after restarting the app and triggering multiple calls to on_expose_event as described above. One thing I've noticed is that the app crashes *after* printing "Get cairo done". When I comment out the call to create_cairo_context, the problem dissapears, so I'm pretty sure there is something wrong with this line.The error happens on clean installed Windows XP machines. I have tested both apps (original and minimal) on a colleague's notebook, which also has Windows XP, but it doesn't crash there. I suppose there is some dependency that is available/up to date in our computers but not in the computers where the application crashes. I have updated DirectX and installed Visual Studio C++ 2005 Redistributable on one of the problematic machines, but the problem persists.The original app, which draws a graph on the DrawingArea, doesn't necessarily crash the first time either. It may work fine the first time after rebooting, but is more prone to fail the second time.I am thinking about compiling and testing with MinGW to see if that solves the problem. I'll also try to compile a debug version and try to use a debugger. I have suspected the version of gdi32.dll might have something to do, seeing that libcairo-2.dll depends on this dll according to Dependency Walker, but until now it's just an speculation. Other than that, I'm out of ideas.I'll be trying these ideas for the time being. Hopefully someone has more suggestions or knows what is going on with the code above.Thank you,Jong Bor.I've run the minimal program using WinDbg. Here's the error message:HEAP[app_name.exe]: Invalid Address specified to RtlFreeHeap( 00FA0000, 00F05210 )(bb0.a64): Break instruction exception - code 80000003 (first chance)eax=00f05208 ebx=00f05208 ecx=7c92eb05 edx=0012f2d6 esi=00fa0000 edi=00f05208eip=7c911230 esp=0012f4e0 ebp=0012f4e4 iopl=0 nv up ei pl nz na po nccs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202ntdll!DbgBreakPoint:7c911230 cc int 3And the stack traceWARNING: Stack unwind information not available. Following frames may be wrong.ntdll!DbgBreakPointntdll!RtlpNtMakeTemporaryKey+0x6b74ntdll!RtlpNtMakeTemporaryKey+0x7d5antdll!RtlInitializeSListHead+0x115c0ntdll!iswdigit+0x128MSVCR80_940000!free+0xcdimage00400000+0x141dgtkmm_2_4!Gtk::Widget_Class::expose_event_callback+0x77libgtk_win32_2_0_0!gtk_marshal_VOID__UINT_STRING+0x111libgobject_2_0_0!g_closure_invoke+0xf6libgobject_2_0_0!g_signal_has_handler_pending+0xaf8libgobject_2_0_0!g_signal_emit_valist+0x4f7libgobject_2_0_0!g_signal_emit+0x1alibgtk_win32_2_0_0!gtk_widget_activate+0x227.libgtk_win32_2_0_0!gtk_widget_send_expose+0x149libgtk_win32_2_0_0!gtk_main_do_event+0x6d0libgdk_win32_2_0_0!gdk_window_clear_area_e+0xd34libgdk_win32_2_0_0!gdk_window_process_all_updates+0x7clibgdk_win32_2_0_0!gdk_window_process_all_updates+0xf3libglib_2_0_0!g_source_remove_poll+0x2calibglib_2_0_0!g_main_context_acquire+0x55flibglib_2_0_0!g_main_loop_run+0x159libgtk_win32_2_0_0!gtk_main+0xa8gtkmm_2_4!Gtk::Main::run+0xc7image00400000+0x1b4ckernel32!RegisterWaitForInputIdle+0x49Seemingly, there is a memory management somewhere (mine or Cairo's, I don't know). But then, the code is extremely simple, where could there be an error? I'm suspecting this is an incompatibility of Cairo with Windows, or some misunderstanding of Gtk programming from me.