pidgin bug tracker http://developer.pidgin.im/ticket/5662

I've installed the dlls from http://www.gtk.org/download-windows.html and was able to produce the same crash from pidgin. Though they also caused many visual artifacts in pidgin, mostly icons appearing as red X's all over the place.

Created attachment 16251 [details]
crash stack with newest DLLs

Created attachment 16252 [details]
debug log of pidgin (contains gtk print statements on the last couple lines)

better summary...

Using the gtk 2.12.10 available for download on GTK+ for windows site  I see this printed out

(23:54:51) stun: got public ip 208.120.218.196
(23:55:08) Gdk: gdkgc-win32.c:823: SaveDC failed: Not enough storage is available to process this command.
(23:55:08) Gdk: gdkdrawable-win32.c:1534: BitBlt failed: The operation completed successfully.
(23:55:08) Gdk: gdkgc-win32.c:963: RestoreDC failed: The parameter is incorrect.
(23:55:08) Gdk: gdkgc-win32.c:823: SaveDC failed: Not enough storage is available to process this command.
(23:55:08) Gdk: gdkgc-win32.c:963: RestoreDC failed: The parameter is incorrect.
(23:55:08) Gdk: gdkpixmap-win32.c:302: CreateDIBSection failed: The parameter is incorrect.
(23:55:08) Gdk: gdkpixmap-win32.c:114: DeleteObject failed: The operation completed successfully.
(23:55:08) Gdk: _gdk_drawable_ref_cairo_surface: assertion `GDK_IS_DRAWABLE (drawable)' failed


And here is the stack trace

-------------------

Error occured on Friday, July 4, 2008 at 23:55:08.

Windows Version 5.1 Build 2600 Service Pack 2

C:\Program Files\Pidgin\pidgin.exe caused an Access Violation at location 68dd6cff in module C:\Program Files\Common Files\GTK\2.0\bin\libcairo-2.dll Reading from location 000000bc.

Registers:
eax=00000000 ebx=01c4e188 ecx=ffffffff edx=fffffd97 esi=01bcc858 edi=063e0fe8
eip=68dd6cff esp=0022f330 ebp=0022f348 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00210206

Call stack:
68DD6CFF C:\Program Files\Common Files\GTK\2.0\bin\libcairo-2.dll  cairo_surface_set_device_offset
         C:\Program Files\Common Files\GTK\2.0\bin\libgdk-win32-2.0-0.dll [2.12.10.0]
6C35B347 C:\Program Files\Common Files\GTK\2.0\bin\libgdk-win32-2.0-0.dll  gdk_window_begin_paint_region
         C:\Program Files\Common Files\GTK\2.0\bin\libgtk-win32-2.0-0.dll [2.12.10.0]
6188A388 C:\Program Files\Common Files\GTK\2.0\bin\libgtk-win32-2.0-0.dll  gtk_main_do_event
         C:\Program Files\Common Files\GTK\2.0\bin\libgdk-win32-2.0-0.dll [2.12.10.0]
6C35C4C3 C:\Program Files\Common Files\GTK\2.0\bin\libgdk-win32-2.0-0.dll  gdk_window_clear_area_e
6C35C608 C:\Program Files\Common Files\GTK\2.0\bin\libgdk-win32-2.0-0.dll  gdk_window_process_all_updates
         C:\Program Files\Common Files\GTK\2.0\bin\libgtk-win32-2.0-0.dll [2.12.10.0]
617E7689 C:\Program Files\Common Files\GTK\2.0\bin\libgtk-win32-2.0-0.dll  gtk_container_check_resize
         C:\Program Files\Common Files\GTK\2.0\bin\libgdk-win32-2.0-0.dll [2.12.10.0]
6C3417E8 C:\Program Files\Common Files\GTK\2.0\bin\libgdk-win32-2.0-0.dll  gdk_threads_set_lock_functions
         C:\Program Files\Common Files\GTK\2.0\bin\libglib-2.0-0.dll [2.16.3.0]
685E70D7 C:\Program Files\Common Files\GTK\2.0\bin\libglib-2.0-0.dll  g_main_context_dispatch
685E85AB C:\Program Files\Common Files\GTK\2.0\bin\libglib-2.0-0.dll  g_main_context_acquire
685E879A C:\Program Files\Common Files\GTK\2.0\bin\libglib-2.0-0.dll  g_main_loop_run
         C:\Program Files\Common Files\GTK\2.0\bin\libgtk-win32-2.0-0.dll [2.12.10.0]
618895EE C:\Program Files\Common Files\GTK\2.0\bin\libgtk-win32-2.0-0.dll  gtk_main
         C:\Program Files\Pidgin\pidgin.dll [2.4.3.0]
64A8ED51 C:\Program Files\Pidgin\pidgin.dll  pidgin_main  /home/stu/build/win32/pidgin-2.4.3-mtn/pidgin/gtkmain.c:897
         C:\Program Files\Pidgin\pidgin.exe [2.4.3.0]
00401EFF C:\Program Files\Pidgin\pidgin.exe  WinMain@16  win32/winpidgin.c:658
00402736 C:\Program Files\Pidgin\pidgin.exe
004010B6 C:\Program Files\Pidgin\pidgin.exe  __mingw_CRTStartup  /home/bitwalk/redhat/BUILD/mingw-3.14/mingw-runtime-3.14/crt1.c:237

cairo is 1.6.4-2 in this version of windows gtk

_gdk_drawable_ref_cairo_surface() can return NULL, but gdk_window_begin_paint_region() does not check if it did so before passing the result to cairo_surface_set_device_offset(), which also doesn't check if it's NULL before dereferencing it. 

Is it possible my error is a NULL pointer dereference?
-------------------------------------------------------
Excerpt from gdkwindow.c line 970-1026 
...
void	      
gdk_window_begin_paint_region (GdkWindow *window,
			       GdkRegion *region)
{
...
  paint->surface = _gdk_drawable_ref_cairo_surface (paint->pixmap);
  cairo_surface_set_device_offset (paint->surface,
				   - paint->x_offset, - paint->y_offset);
...
}
...
-------------------------------------------------------
Excerpt from  gdkdraw.c lines 1257-1275
...
/**
 * _gdk_drawable_ref_cairo_surface:
 * @drawable: a #GdkDrawable
 * 
 * Obtains a #cairo_surface_t for the given drawable. If a
 * #cairo_surface_t for the drawable already exists, it will be
 * referenced, otherwise a new surface will be created.
 * 
 * Return value: a newly referenced #cairo_surface_t that points
 *  to @drawable. Unref with cairo_surface_destroy()
 **/
cairo_surface_t *
_gdk_drawable_ref_cairo_surface (GdkDrawable *drawable)
{
  g_return_val_if_fail (GDK_IS_DRAWABLE (drawable), NULL);

  return GDK_DRAWABLE_GET_CLASS (drawable)->ref_cairo_surface (drawable);
}
....

GTK bug - http://bugzilla.gnome.org/show_bug.cgi?id=543209

Cairo bug - http://bugs.freedesktop.org/show_bug.cgi?id=15761

Pidgin/gaim bugs:

http://developer.pidgin.im/ticket/5662
http://developer.pidgin.im/ticket/5893
http://developer.pidgin.im/ticket/4826
http://developer.pidgin.im/ticket/5593
http://developer.pidgin.im/ticket/5594
http://developer.pidgin.im/ticket/6252

Mirror of old gaim sourceforge tracker:
http://article.gmane.org/gmane.comp.gnome.gaim.bugs/175

(In reply to comment #8)
> _gdk_drawable_ref_cairo_surface() can return NULL, but
> gdk_window_begin_paint_region() does not check if it did so before passing the
> result to cairo_surface_set_device_offset(), which also doesn't check if it's
> NULL before dereferencing it. 

That's quite possible. And for cairo, this is the expected behavior of this
function.

If a cairo function returns a cairo_status_t value, then it will return
CAIRO_STATUS_NULL_POINTER if you pass it NULL. But the void functions
will simply dereference the pointer and crash.

If you're interested in seeing that behavior change at all, then that
would be a discussion to be had on the cairo mailing list, (see
http://cairographics.org/lists )

-Carl

(In reply to comment #11)
> (In reply to comment #8)
> > _gdk_drawable_ref_cairo_surface() can return NULL, but
> > gdk_window_begin_paint_region() does not check if it did so before passing the
> > result to cairo_surface_set_device_offset(), which also doesn't check if it's
> > NULL before dereferencing it. 
> 
> That's quite possible. And for cairo, this is the expected behavior of this
> function.
> 
> If a cairo function returns a cairo_status_t value, then it will return
> CAIRO_STATUS_NULL_POINTER if you pass it NULL. But the void functions
> will simply dereference the pointer and crash.
> 
> If you're interested in seeing that behavior change at all, then that
> would be a discussion to be had on the cairo mailing list, (see
> http://cairographics.org/lists )
> 
> -Carl
> 

Well I think I may have erred in filing this bug report here in the first place, as that GTK function should be checking the return value of the other GTK function first knowing that libcairo will happily crash on NULL input.  It's just that the crash stack first implicated cairo, since that's the library it crashed in.

I'm just trying to figure out who is to blame so I can get this fixed. If either cairo, or GTK check for NULL before dereferencing then it solves the problem, I will leave it up to the 2 development communities to choose who should be the one checking.

The crash is caused by GTK+ passing a NULL surface to cairo, something which should not happen. In particular, it looks like GTK+ made an error when trying to create the win32 drawable and that should be fixed at source.