Has this been tiraged?  The problem is still here.

One more thing:  I'm running with the ati driver with the ATI Radeon 9000 IGP chip and kernel 2.6.32.3.   I configure drm with  --enable-radeon-experimental-api.  Could this be an issue?  I added the configure flag from a suggestion in dealing with bug 25355.

(In reply to comment #2)
> One more thing:  I'm running with the ati driver with the ATI Radeon 9000 IGP
> chip and kernel 2.6.32.3.   I configure drm with 
> --enable-radeon-experimental-api.  Could this be an issue?  I added the
> configure flag from a suggestion in dealing with bug 25355.
> 

You need mesa and xf86-video-ati built against libdrm built with --enable-radeon-experimental-api in order to use KMS.

I build drm 1st, so it should be enabled with the configure flag.   I assume that the other modules autotdetect it's presence no?  Moreover, if not, it still should work, albeit without KMS.

(In reply to comment #4)
> I build drm 1st, so it should be enabled with the configure flag.   I assume
> that the other modules autotdetect it's presence no?  Moreover, if not, it
> still should work, albeit without KMS.
> 

correct.

I'm still seeing this bug (I think).  Here's a recent console log/backtrace after upgrading to the current git/master.

*********************************WARN_ONCE*********************************
File radeon_dma.c function radeonReleaseDmaRegions line 340
Leaking dma buffer object!
***************************************************************************
*** glibc detected *** ./bin_unix/native_client: free(): invalid pointer:
0x084576b4 ***
======= Backtrace: =========
/lib/libc.so.6[0xb7307564]
/lib/libc.so.6(cfree+0x90)[0xb730b010]
/usr/lib/dri/r200_dri.so[0xb6484d31]
/usr/lib/dri/r200_dri.so[0xb6482997]
/usr/lib/dri/r200_dri.so[0xb647ea9e]
/usr/lib/dri/r200_dri.so[0xb644a5d1]
/usr/lib/dri/r200_dri.so[0xb6441cc8]
/usr/lib/libGL.so.1[0xb75700b9]
/usr/lib/libGL.so.1[0xb7537c3a]
/usr/lib/libGL.so.1(glXDestroyContext+0x18)[0xb7537d9e]
/usr/lib/libSDL-1.2.so.0[0xb76cb1b4]

Here's a backtrace I was able to capture after the last crash (with your patch
applied).

#5  0xb6484d31 in radeonReleaseDmaRegions (rmesa=0x8457698) at radeon_dma.c:343
        dma_bo = (struct radeon_dma_bo *) 0x84576b4
        temp = (struct radeon_dma_bo *) 0x96d8cf8
        expire_at = 64069
        time = 63969
        __FUNCTION__ = "radeonReleaseDmaRegions"
#6  0xb6482997 in rcommonFlushCmdBuf (rmesa=0x8457698, 
    caller=0xb66bb428 "radeonDestroyContext") at radeon_common.c:1224
        ret = -1236282016
#7  0xb647ea9e in radeonDestroyContext (driContextPriv=0x842eac0)
    at radeon_common_context.c:308
        ctx = (GLcontext *) 0x0
        radeon = (radeonContextPtr) 0x8457698
        current = (radeonContextPtr) 0x0
        __PRETTY_FUNCTION__ = "radeonDestroyContext"
        __FUNCTION__ = "radeonDestroyContext"
#8  0xb644a5d1 in r200DestroyContext (driContextPriv=0x842eac0)
    at r200_context.c:511
        i = 6
        rmesa = (r200ContextPtr) 0x8457698
#9  0xb6441cc8 in driDestroyContext (pcp=0x842eac0) at ../common/dri_util.c:551
No locals.
#10 0xb75700b9 in driDestroyContext (context=0x84554d0, psc=0x8454aa0, 
    dpy=0x84116d8) at dri_glx.c:482
        pcp = (__GLXDRIcontextPrivate *) 0x84554d0
#11 0xb7537c3a in DestroyContext (dpy=0x84116d8, gc=0x842cc10) at glxcmds.c:548
        req = (xGLXDestroyContextReq *) 0xb73e3ff4
        xid = 67108866
        opcode = 151 '\227'
        imported = 0 '\0'
#12 0xb7537d9e in glXDestroyContext (dpy=0x84116d8, gc=0x842cc10)
    at glxcmds.c:584
No locals.
#13 0xb76cb1b4 in X11_GL_Shutdown () from /usr/lib/libSDL-1.2.so.0
No locals.
#14 0x0842cc10 in ?? ()
No symbol table info available.
#15 0x00000000 in ?? ()
No symbol table info available.

does this commit help?
http://cgit.freedesktop.org/mesa/mesa/commit/?h=7.8&id=e9c2c4a76466fc1ccfbf4d5de048414f7126b940

This looks like screen is destroyed before context. Can someone
reproduce this in valgrind and attach the log?

It may not crash in valgrind but there should be double free report
with same backtrace.

In response to comment #7; I had applied the patch (I reported bug 27071).  Something else was going on there which is now fixed.   This problem still remains.

Created attachment 34132 [details]
Valgrind output

Output is quite strange--basically it looks as if valgrind crashed before giving its final report.

Created attachment 34133 [details]
Better valgrind output

It seems that valgrind doesn't trace scripts.  The attached was obtained by running the program directly.

I had to kill things as soon as the program started (no crash this time) as it's too slow under valgrind; nonetheless, there seems to be some useful  information in the output.

ping.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/274.