On Fri, Nov 5, 2010 at 1:30 PM, Jong Bor Lee <jlee@xxxxxxxxxxxxx> 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=00f05208
eip=7c911230 esp=0012f4e0 ebp=0012f4e4 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
ntdll!DbgBreakPoint:
7c911230 cc int 3
And the stack trace
WARNING: Stack unwind information not available. Following frames may be wrong.
ntdll!DbgBreakPoint
ntdll!RtlpNtMakeTemporaryKey+0x6b74
ntdll!RtlpNtMakeTemporaryKey+0x7d5a
ntdll!RtlInitializeSListHead+0x115c0
ntdll!iswdigit+0x128
MSVCR80_940000!free+0xcd
image00400000+0x141d
gtkmm_2_4!Gtk::Widget_Class::expose_event_callback+0x77
libgtk_win32_2_0_0!gtk_marshal_VOID__UINT_STRING+0x111
libgobject_2_0_0!g_closure_invoke+0xf6
libgobject_2_0_0!g_signal_has_handler_pending+0xaf8
libgobject_2_0_0!g_signal_emit_valist+0x4f7
libgobject_2_0_0!g_signal_emit+0x1a
libgtk_win32_2_0_0!gtk_widget_activate+0x227.
libgtk_win32_2_0_0!gtk_widget_send_expose+0x149
libgtk_win32_2_0_0!gtk_main_do_event+0x6d0
libgdk_win32_2_0_0!gdk_window_clear_area_e+0xd34
libgdk_win32_2_0_0!gdk_window_process_all_updates+0x7c
libgdk_win32_2_0_0!gdk_window_process_all_updates+0xf3
libglib_2_0_0!g_source_remove_poll+0x2ca
libglib_2_0_0!g_main_context_acquire+0x55f
libglib_2_0_0!g_main_loop_run+0x159
libgtk_win32_2_0_0!gtk_main+0xa8
gtkmm_2_4!Gtk::Main::run+0xc7
image00400000+0x1b4c
kernel32!RegisterWaitForInputIdle+0x49
Seemingly, 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.
_______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
