eog crashed with SIGABRT in __assert_fail_base()

[joshg]

this occured while opening shotwell

ProblemType: Crash
DistroRelease: Ubuntu 12.04
Package: eog 3.3.91-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-18.28-generic 3.2.9
Uname: Linux 3.2.0-18-generic i686
ApportVersion: 1.94.1-0ubuntu1
Architecture: i386
Date: Thu Mar 8 20:48:36 2012
ExecutablePath: /usr/bin/eog
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Beta i386 (20110904)
ProcCmdline: eog /home/username/Scrivania/Saint-Sauveur_in_Chora_-_Christ_Pantocrator.jpg
Signal: 6
SourcePackage: eog
StacktraceTop:
 raise () from /lib/i386-linux-gnu/libc.so.6
 abort () from /lib/i386-linux-gnu/libc.so.6
 ?? () from /lib/i386-linux-gnu/libc.so.6
 __assert_fail () from /lib/i386-linux-gnu/libc.so.6
 _XAllocID () from /usr/lib/i386-linux-gnu/libX11.so.6
Title: eog crashed with SIGABRT in raise()
UpgradeStatus: Upgraded to precise on 2012-03-03 (5 days ago)
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare scanner

[Apport retracing service (apport)]

StacktraceTop:
 __assert_fail_base (fmt=0xb75b1698 <Address 0xb75b1698 out of bounds>, assertion=0x76ad79 "ret != inval_id", file=0x76acea "../../src/xcb_io.c", line=528, function=0x76adfe "_XAllocID") at assert.c:94
 __GI___assert_fail (assertion=0x76ad79 "ret != inval_id", file=0x76acea "../../src/xcb_io.c", line=528, function=0x76adfe "_XAllocID") at assert.c:103
 _XAllocID (dpy=0x8cdfad0) at ../../src/xcb_io.c:528
 XRenderCreatePicture (dpy=0x8cdfad0, drawable=60817935, format=0x8d17c70, valuemask=256, attributes=0xbfaad57c) at ../../src/Picture.c:90
 _cairo_xlib_surface_ensure_src_picture (surface=0x90b6bc0, display=<optimized out>) at /build/buildd/cairo-1.10.2/src/cairo-xlib-surface.c:1070

[Bryce Harrington (bryce)]

 __assert_fail_base (fmt=0xb75b1698 <Address 0xb75b1698 out of bounds>, assertion=0x76ad79 "ret != inval_id", file=0x76acea "../../src/xcb_io.c", line=528, function=0x76adfe "_XAllocID") at assert.c:94

Would the 0xb75b1698 being out of bounds be the problem here? But I'm not sure where that comes from.

I'm not certain whether this actually is a libx11 bug; could be invalid memory higher up in the stack or something.