Created attachment 31422 [details]
Output of valgrind

With git drm-radeon-testing merged into the latest 2.6.32 prerelease & git libdrm and mesa, Machinarium (demo available here: http://machinarium.net/demo/) crashes on startup. It's an Adobe Flash 10 binary.

Running the binary under valgrind reveals that the crash occurs here:

==30198== Invalid read of size 4
==30198==    at 0xA8CC209: radeonFlush (radeon_common.c:1131)
==30198==    by 0xA8C7628: r600DeleteTexture (radeon_cmdbuf.h:118)
==30198==    by 0xA94FE29: _mesa_free_texture_data (texstate.c:799)
==30198==    by 0xA8E8C27: _mesa_free_context_data (context.c:977)
==30198==    by 0xA8E8DF5: _mesa_destroy_context (context.c:1039)
==30198==    by 0xA8CAD5D: radeonDestroyContext (radeon_common_context.c:328)
==30198==    by 0xA8A2DB6: driDestroyContext (dri_util.c:545)
==30198==    by 0xA8582A8: dri2DestroyContext (dri2_glx.c:95)
==30198==    by 0xA832345: DestroyContext (glxcmds.c:556)

and dropping into gdb reveals that the DrawBuffer is 0x0 in the context (ctx):

(gdb) l
1126			radeon->dma.flush( ctx );
1127	
1128		if (radeon->cmdbuf.cs->cdw)
1129			rcommonFlushCmdBuf(radeon, __FUNCTION__);
1130	
1131		if ((ctx->DrawBuffer->Name == 0) && radeon->front_buffer_dirty) {
1132			__DRIscreen *const screen = radeon->radeonScreen->driScreen;
1133	
1134			if (screen->dri2.loader && (screen->dri2.loader->base.version >= 2)
1135				&& (screen->dri2.loader->flushFrontBuffer != NULL)) {
(gdb) p ctx
$5 = (GLcontext *) 0xa571460
(gdb) p ctx->DrawBuffer
$6 = (GLframebuffer *) 0x0

Now, this could be an Abobe bug: there are a stack of other errors from valgrind (attached), but it seems that mesa isn't being defensive enough here regardless. The game runs fine with LIGL_ALWAYS_SOFTWARE=1 set.

Happy to do any debugging on request, although the Machinarium demo is freely available. (The above comes from the full game, I haven't tried the demo yet.)

NB. Is DRI/Radeon the right place for this? I'll resubmit if not.