Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Mar 2012 15:28:30 -0700 (PDT)
From:      "Ronald F.Guilmette" <rfg@tristatelogic.com>
To:        FreeBSD-gnats-submit@FreeBSD.org
Subject:   ports/166163: gthumb port crashes (SIGSEGV) within the Mesa/DRI library
Message-ID:  <20120315222830.1BA255084A@segfault.tristatelogic.com>
Resent-Message-ID: <201203152230.q2FMU1tA077905@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         166163
>Category:       ports
>Synopsis:       gthumb port crashes (SIGSEGV) within the Mesa/DRI library
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-ports-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Mar 15 22:30:01 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator:     Ronald F. Guilmette
>Release:        FreeBSD 8.2-RELEASE amd64
>Organization:
Entropy
>Environment:
	FreeBSD 8.2-RELEASE GENERIC amd64

>Description:
	The gthumb program (see the gthumb port) crashes with a SIGSEGV.

	It just started doing this after I installed an ATI Radeon (r300)
	based video card.

	A stack trace is attached below.  This makes it clear that the
	problem is actually occuring in the DRI/Mesa library.  It would
	appear that the FreeBSD port of this library is not being actively/
	properly maintained, and that thus, it has not been updated since
	v7.4.4, whereas the current version is 8.0.1.

	Here is the gdb stack trace for the SIGSEGV crash of gthumb:
	
	#0  0x0000000805453233 in r300UpdateWindow (ctx=0x80534a000)
	    at r300_state.c:1066
	1066            GLfloat sx = v[MAT_SX];
	[New Thread 8052041c0 (LWP 100247)]
	(gdb) where
	#0  0x0000000805453233 in r300UpdateWindow (ctx=0x80534a000)
	    at r300_state.c:1066
	#1  0x0000000805456a83 in r300ResetHwState (r300=0x8052f8000)
	    at r300_state.c:2195
	#2  0x00000008054588ec in r300InitState (r300=0x8052f8000) at r300_state.c:2750
	#3  0x00000008054451fd in r300CreateContext (glVisual=0x805308700, 
	    driContextPriv=0x80524d220, sharedContextPrivate=0x0) at r300_context.c:382
	#4  0x000000080543b5bf in radeonCreateContext (glVisual=0x805308700, 
	    driContextPriv=0x80524d220, sharedContextPriv=0x0) at radeon_screen.c:1143
	#5  0x0000000805435793 in driCreateNewContext (psp=0x80524e480, 
	    config=0x805308700, render_type=32788, shared=0x0, hwContext=3, 
	    data=0x80524d1f0) at ../common/dri_util.c:587
	#6  0x0000000802f2d70f in driCreateContext () from /usr/local/lib/libGL.so.1
	#7  0x0000000802f08320 in CreateContext () from /usr/local/lib/libGL.so.1
	#8  0x0000000802f086dc in glXCreateNewContext () from /usr/local/lib/libGL.so.1
	#9  0x0000000800a61255 in cogl_pango_glyph_cache_new ()
	   from /usr/local/lib/libclutter-glx-1.0.so.0
	#10 0x00000008009ebfdb in clutter_feature_available ()
	   from /usr/local/lib/libclutter-glx-1.0.so.0
	#11 0x00000008009f6045 in clutter_get_option_group_without_init ()
	   from /usr/local/lib/libclutter-glx-1.0.so.0
	#12 0x00000008009f626f in clutter_init ()
	   from /usr/local/lib/libclutter-glx-1.0.so.0
	#13 0x00000000004c3b59 in main (argc=1, argv=0x7fffffffe300) at main.c:561
	(gdb) print v
	$1 = (const GLfloat *) 0x800000000
	(gdb) print *$1
	Cannot access memory at address 0x800000000
	(gdb) 
	
	
	I did some grepping around and found that MAT_SX is #defined to the
	value 0.  Thus, the gdb command "print v[0]" or equivalently "print *v"
	should give a clearer picture of what is causing the problem, and as
	you can see, indeed it does.  The process virtual space at 0x800000000
	is apparently not mapped in.  Thus, the attempt to fetch the contents
	of v[MAT_SX] quite reasonably results in a SIGSEGV and a coredump.
	
	After getting this far, I read the page:
	
	   http://dri.freedesktop.org/wiki/DriTroubleshooting
	
	and checked everything I could that was listed there and all seems to
	be well.  The radeon.ko module does seem to be loaded into the kernel,
	and the folliowing line does exist in my /var/log/Xorg.0.log file:
	
	(II) RADEON(0): Direct rendering enabled
	
	Additionally, after doing "setenv LIBGL_DEBUG verbose" and re-running
	gthumb, everything seems to be OK.
	
	% gthumb .
	libGL: XF86DRIGetClientDriverName: 5.3.0 r300 (screen 0)
	libGL: OpenDriver: trying /usr/local/lib/dri/r300_dri.so
	drmOpenDevice: node name is /dev/dri/card0
	drmOpenDevice: open result is 6, (OK)
	drmOpenByBusid: Searching for BusID pci:0000:02:00.0
	drmOpenDevice: node name is /dev/dri/card0
	drmOpenDevice: open result is 6, (OK)
	drmOpenByBusid: drmOpenMinor returns 6
	drmOpenByBusid: drmGetBusid reports pci:0000:02:00.0
	libGL error: 
	Can't open configuration file /etc/drirc: No such file or directory.
	libGL error: 
	Can't open configuration file /usr/home/rfg/.drirc: No such file or directory.
	Segmentation fault (core dumped)


>How-To-Repeat:
	Get yourself an r300-based Radeon card, install it into your amd64
	machine, then install the gthumb port and just simply try to run
	the thing.  (It will crash with the SIGSEGV.)
>Fix:
	I do believe that somebody should update the dri port to something
	rather more fresh.
>Release-Note:
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120315222830.1BA255084A>