Bug 32822 - xorg-server-1.9.2.902 segfaults in DrawableGone during shutdown
Summary: xorg-server-1.9.2.902 segfaults in DrawableGone during shutdown
Status: RESOLVED INVALID
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
: 32870 32932 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-01-04 05:05 UTC by Hugo Mildenberger
Modified: 2018-06-12 18:43 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Refcnt the drawable (4.06 KB, patch)
2011-01-04 05:11 UTC, Chris Wilson
no flags Details | Splinter Review

Description Hugo Mildenberger 2011-01-04 05:05:57 UTC
That error happened on two machines, both with i915 driven, but different graphic adapters, while trying to terminate a KDE session itself using OpenGL rendering. I discovered it first while having enabled AutoLogin and AutoLoginAgain in kdmrc, running /etc/init.d/xdm stop, and noticed X crashing during shutdown. It does not happen when no user session is active any more.


X.Org X Server 1.9.2.902 (1.9.3 RC 2)
Release Date: 2010-12-03
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.36-hardened-r1 x86_64 Gentoo
Current Operating System: Linux localhost 2.6.36-hardened-r6 #5 SMP Fri Dec 31 15:50:31 CET 2010 x86_64
Kernel command line: BOOT_IMAGE=l2.6.36hr6 ro root=804 i8042.reset
Build Date: 08 December 2010  11:09:47PM
Current version of pixman: 0.20.0

gdb $(which X) --core="0:0-X.core"
[...]
(gdb)
in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x000002b3562039d5 in abort () at abort.c:92
#2  0x0000000fd200046e in OsAbort () at utils.c:1260
#3  0x0000000fd200cb0d in ddxGiveUp () at xf86Init.c:940
#4  0x0000000fd1ffe06d in AbortServer () at log.c:424
#5  0x0000000fd1ffe8b0 in FatalError (f=0xfd2115a08 "Caught signal %d (%s).
Server aborting\n") at log.c:552
#6  0x0000000fd1fff74e in OsSigHandler (signo=11, sip=0x4, unused=<value
optimized out>) at osinit.c:156
#7  <signal handler called>
#8  0x000002b354660d98 in DrawableGone (glxPriv=0xfd53e6c90, xid=0) at
glxext.c:133
#9  0x0000000fd1fe956c in FreeClientResources (client=0xfd23868c0) at
resource.c:859
#10 0x0000000fd1fe9636 in FreeAllResources () at resource.c:876
#11 0x0000000fd1fc038e in main (argc=11, argv=0x39ca60623f8, envp=<value
optimized out>) at main.c:305
(gdb) list DrawableGone
121     /*
122     ** Destroy routine that gets called when a drawable is freed.  A
drawable
123     ** contains the ancillary buffers needed for rendering.
124     */
125     static Bool DrawableGone(__GLXdrawable *glxPriv, XID xid)
126     {
127         __GLXcontext *c, *next;
128
129         /* If this drawable was created using glx 1.3 drawable
130          * constructors, we added it as a glx drawable resource under both
131          * its glx drawable ID and it X drawable ID.  Remove the other
132          * resource now so we don't a callback for freed memory. */
133         if (glxPriv->drawId != glxPriv->pDraw->id) {
134             if (xid == glxPriv->drawId)
135                 FreeResourceByType(glxPriv->pDraw->id, __glXDrawableRes,
TRUE);
136             else
137                 FreeResourceByType(glxPriv->drawId, __glXDrawableRes,
TRUE);
138         }
139
140         for (c = glxAllContexts; c; c = next) {
(gdb) sele 8
(gdb) print glxPriv
$1 = (__GLXdrawable *) 0xfd53e6c90
(gdb) print *glxPriv
$2 = {destroy = 0xdd8eddff0d010d3a, swapBuffers = 0xffffffffffffffff,
copySubBuffer = 0xffffffffffffffff, waitX = 0xffffffffffffffff, waitGL =
0xf4f0f00ffffffbf, pDraw = 0x0,
  drawId = 0, type = 0, config = 0x7f597f9f10021030, target = 3468349151,
  format = 4176345343, eventMask = 18446744073709551615}
  (gdb) print glxPriv->pDraw
  $3 = (DrawablePtr) 0x0

Interestingly, nearby all heap-related bugs finally end up in DrawableGone, at least since version 1.8.1; but I've seen posts dating many years ago calling for not to call DrawableGone with a NULL value in glxpriv->pDraw. I suspect that changing line 133 into 

     if (glxPriv->pDraw && glxPriv->drawId != glxPriv->pDraw->id) {

could solve the issue here, assuming a NULL value in glxPriv->pDraw really stands for "already freed"
Comment 1 Chris Wilson 2011-01-04 05:11:06 UTC
Created attachment 41618 [details] [review]
Refcnt the drawable

However Kirstian wants a simpler fix.
Comment 2 Hugo Mildenberger 2011-01-04 10:26:22 UTC
Yes, your patch apparently fixed the problem. But before that, this patch

  https://bugs.freedesktop.org/attachment.cgi?id=40794&action=edit

fixed it too. When applying both patches, I still get warnings in the
logs:

[ 11413.406] (EE) DANGER: DoCreateGLXPixmap - drawableId 23068871, pDraw->id 0
[ 11413.406] (EE) ... fixing up
[ 11415.254] (EE) DANGER: DoCreateGLXPixmap - drawableId 23068873, pDraw->id 0
[ 11415.254] (EE) ... fixing up

While using gdb from a remote machine, I saw that this part of code exclusively runs when you actively change something, e.g., in Konqueror's address bar. Exactly this was the main symptom of a memory bug becoming manifest between xorg-server-1.8.0 and xorg-server-1.8.1.901 when krh's patch 0460a76b9ae25fe26f683f0cbff1e4157287cf56 had been committed. The problem disappeared when one was forced to  switch to KMS on i915,  but certainly smolders further in the dark.
Comment 3 Michel Dänzer 2011-01-11 03:04:01 UTC
*** Bug 32870 has been marked as a duplicate of this bug. ***
Comment 4 Toralf Förster 2011-01-31 07:44:43 UTC
(In reply to comment #1)

> However Kirstian wants a simpler fix.
Which BTW didn't make it in 1.9.3.902 isn't it ?
Comment 5 Toralf Förster 2011-02-10 11:19:05 UTC
*** Bug 32932 has been marked as a duplicate of this bug. ***
Comment 6 Adam Jackson 2018-06-12 18:43:06 UTC
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.


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.