(In reply to comment #0)
> Please let me know if I can provide any additional information.

See http://intellinuxgraphics.org/how_to_report_bug.html

http://bugs.debian.org/617757 contains much of the requested information.  I'll gather the rest and post it here.

for reference, I have a stack trace:

#0  0x00d4e416 in __kernel_vsyscall ()
#1  0x47ce85df in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0x47ce9f45 in abort () at abort.c:92
#3  0x47ce0f96 in __assert_fail (assertion=0x31dc0f7 "!texImage->Data", file=0x31dc0e5 "intel_tex_image.c", line=726, function=0x31dc2bb "intelSetTexBuffer2")
    at assert.c:81
#4  0x02f9aee6 in intelSetTexBuffer2 (pDRICtx=0x8855a10, target=3553, texture_format=8409, dPriv=0x94fef30) at intel_tex_image.c:726
#5  0x49ff5615 in dri2_bind_tex_image (dpy=0x87fea98, drawable=14682034, buffer=8414, attrib_list=0x0) at dri2_glx.c:706
#6  0x49fcc104 in __glXBindTexImageEXT (dpy=0x87fea98, drawable=14682034, buffer=8414, attrib_list=0x0) at glxcmds.c:2294
#7  0x00b47ef3 in _cogl_texture_pixmap_x11_update_glx_texture (needs_mipmap=0, tex_pixmap=0x955ac00) at ./winsys/cogl-texture-pixmap-x11.c:1038
#8  _cogl_texture_pixmap_x11_update (tex_pixmap=0x955ac00, needs_mipmap=0) at ./winsys/cogl-texture-pixmap-x11.c:1087
#9  0x00b4882e in _cogl_texture_pixmap_x11_pre_paint (tex=0x955ac00, flags=0) at ./winsys/cogl-texture-pixmap-x11.c:1289
#10 0x00b35eb7 in _cogl_texture_pre_paint (handle=0x955ac00, flags=0) at ./cogl-texture.c:816
#11 0x00b26d70 in _cogl_pipeline_layer_pre_paint (layer=0x8f69df8) at ./cogl-pipeline.c:5666
#12 0x00b28244 in _cogl_pipeline_pre_paint_for_layer (pipeline=0x94ff4c0, layer_id=0) at ./cogl-pipeline.c:5675
#13 0x00b14049 in _cogl_rectangles_validate_layer_cb (pipeline=0x94ff4c0, layer_index=0, user_data=0xbfb9e1c0) at ./cogl-primitives.c:618
#14 0x00b24f99 in cogl_pipeline_foreach_layer (pipeline=0x94ff4c0, callback=0xb14010 <_cogl_rectangles_validate_layer_cb>, user_data=0xbfb9e1c0)
    at ./cogl-pipeline.c:761
#15 0x00b13eb6 in _cogl_rectangles_with_multitexture_coords (rects=0xbfb9e214, n_rects=1) at ./cogl-primitives.c:734
#16 0x00b14539 in cogl_rectangle_with_multitexture_coords (x_1=0, y_1=0, x_2=1095, y_2=26, user_tex_coords=0xbfb9e260, user_tex_coords_len=8)
    at ./cogl-primitives.c:895
#17 0x006f8e5c in meta_shaped_texture_paint (actor=0x9275010) at compositor/meta-shaped-texture.c:427

Downstream bug report has some additional files if they're still needed:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/757906

ebassi, any clue what clutter might have done to trigger texImage->Data being present?  Anything that might be special about the texture object before it got TFP treatment?

(In reply to comment #5)
> ebassi, any clue what clutter might have done to trigger texImage->Data being
> present?  Anything that might be special about the texture object before it got
> TFP treatment?

I honestly have no idea. :-)

I can say, though, that I haven't experience the bug any more with Fedora 15 on my GM45 since I reported the bug - so it's possible that something in Cogl, Mutter or the driver fixed this issue for me.

FWIW I haven't seen this in a while either.

A cleanup led to getting the assertion killed anyway:

commit d430e81c3287eba4ee84ca1639a23f92bbe22c8e
Author: Eric Anholt <eric@anholt.net>
Date:   Wed Sep 21 15:17:36 2011 -0700

    intel: Fix improper freeing of texture data in TFP.
    
    If there happened to be ->Data present, we assertion failed instead of
    handling it correctly.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35234
    Acked-by: Kenneth Graunke <kenneth@whitecape.org>