Bug 25597 - [RADEON:UMS:R200C] SIGSEGV in _radeon_bo_unref
Summary: [RADEON:UMS:R200C] SIGSEGV in _radeon_bo_unref
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/R100 (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium critical
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-11 11:58 UTC by David Ronis
Modified: 2019-09-18 18:39 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Valgrind output (9.98 KB, text/plain)
2010-03-16 17:44 UTC, David Ronis
Details
Better valgrind output (53.70 KB, text/plain)
2010-03-16 19:35 UTC, David Ronis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Ronis 2009-12-11 11:58:29 UTC
I occasionally crash in the sauerbrauten game (even after the fix in bug #25355); the problem seems to be game-map related.  I'm following the git/master.  

I see the following on the console:

*********************************WARN_ONCE*********************************
File radeon_dma.c function radeonReleaseDmaRegions line 340
Leaking dma buffer object!
***************************************************************************


From the backtrace it's clear that radeon_bo_unref is being passed a NULL pointer.  My bet is that the culprit is radeonReleaseDmaRegions' calculation of bo (like in bug 25355).

Here's the backtrace:

Program terminated with signal 11, Segmentation fault.
[New process 12045]
#0  0xb641a054 in _radeon_bo_unref (bo=0x0, file=0xb664c012 "radeon_dma.c", 
    func=0xb664c353 "radeonReleaseDmaRegions", line=341)
    at /usr/include/drm/radeon_bo.h:137
137	    bo->cref--;

Thread 1 (process 12045):
#0  0xb641a054 in _radeon_bo_unref (bo=0x0, file=0xb664c012 "radeon_dma.c", 
    func=0xb664c353 "radeonReleaseDmaRegions", line=341)
    at /usr/include/drm/radeon_bo.h:137
No locals.
#1  0xb641b1d0 in radeonReleaseDmaRegions (rmesa=0x843b978) at radeon_dma.c:341
	dma_bo = (struct radeon_dma_bo *) 0x843b994
	temp = (struct radeon_dma_bo *) 0xcdacfd0
	expire_at = 371036
	time = 370936
	__FUNCTION__ = "radeonReleaseDmaRegions"
#2  0xb6418b37 in rcommonFlushCmdBuf (rmesa=0x843b978, 
    caller=0xb664bd88 "radeonFlush") at radeon_common.c:1201
	ret = 138935784
#3  0xb641879f in radeonFlush (ctx=0x8440eb0) at radeon_common.c:1104
	radeon = (radeonContextPtr) 0x843b978
	__FUNCTION__ = "radeonFlush"
#4  0xb6414146 in radeon_firevertices (radeon=0x843b978) at radeon_cmdbuf.h:118
No locals.
#5  0xb6414984 in radeonDestroyContext (driContextPriv=0x84395b0)
    at radeon_common_context.c:308
	ctx = (GLcontext *) 0x8440eb0
	radeon = (radeonContextPtr) 0x843b978
	current = (radeonContextPtr) 0x843b978
	__PRETTY_FUNCTION__ = "radeonDestroyContext"
	__FUNCTION__ = "radeonDestroyContext"
#6  0xb63e259e in r200DestroyContext (driContextPriv=0x84395b0)
    at r200_context.c:509
	i = 6
	rmesa = (r200ContextPtr) 0x843b978
#7  0xb63d9d2d in driDestroyContext (pcp=0x84395b0) at ../common/dri_util.c:546
No locals.
#8  0xb753e09e in driDestroyContext (context=0x8439880, psc=0x8438e18, 
    dpy=0x83f59d0) at dri_glx.c:495
	pcp = (__GLXDRIcontextPrivate *) 0x8439880
#9  0xb7506523 in DestroyContext (dpy=0x83f59d0, gc=0x8410ef8) at glxcmds.c:556
	req = (xGLXDestroyContextReq *) 0xb73afff4
	xid = 65011714
	opcode = 151 '\227'
	imported = 0 '\0'
#10 0xb7506687 in glXDestroyContext (dpy=0x83f59d0, gc=0x8410ef8)
    at glxcmds.c:592
No locals.
#11 0xb76c01b4 in X11_GL_Shutdown () from /usr/lib/libSDL-1.2.so.0
No locals.
#12 0x08410ef8 in ?? ()
No symbol table info available.
#13 0x00000000 in ?? ()
No symbol table info available.
Current language:  auto; currently c
Comment 1 David Ronis 2010-01-19 15:33:39 UTC
Has this been tiraged?  The problem is still here.

Comment 2 David Ronis 2010-01-20 13:11:53 UTC
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.

Comment 3 Alex Deucher 2010-01-20 13:29:21 UTC
(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.
Comment 4 David Ronis 2010-01-20 13:35:30 UTC
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.

Comment 5 Alex Deucher 2010-01-20 14:07:57 UTC
(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.
Comment 6 David Ronis 2010-03-16 09:41:32 UTC
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.
Comment 8 Pauli 2010-03-16 10:07:15 UTC
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.
Comment 9 David Ronis 2010-03-16 11:32:46 UTC
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.

Comment 10 David Ronis 2010-03-16 17:44:27 UTC
Created attachment 34132 [details]
Valgrind output

Output is quite strange--basically it looks as if valgrind crashed before giving its final report.
Comment 11 David Ronis 2010-03-16 19:35:47 UTC
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.
Comment 12 David Ronis 2011-01-14 11:17:44 UTC
ping.
Comment 13 GitLab Migration User 2019-09-18 18:39:59 UTC
-- 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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.