From owner-freebsd-current@FreeBSD.ORG Sun Mar 14 08:04:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0D81106566B for ; Sun, 14 Mar 2010 08:04:22 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8EC088FC23 for ; Sun, 14 Mar 2010 08:04:22 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.3/8.14.3) id o2E84WfN074517; Sun, 14 Mar 2010 08:04:32 GMT (envelope-from kientzle@freebsd.org) Received: from horton.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id d4fxfd99tfdgs3bywy3b7fqezn; Sun, 14 Mar 2010 08:04:32 +0000 (UTC) (envelope-from kientzle@freebsd.org) Message-ID: <4B9C9885.5040601@freebsd.org> Date: Sun, 14 Mar 2010 00:04:21 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.23) Gecko/20100105 SeaMonkey/1.1.18 MIME-Version: 1.0 References: <4B989064.5030105@freebsd.org> <7d6fde3d1003102245l41ab8287r81680aa40281d802@mail.gmail.com> In-Reply-To: <7d6fde3d1003102245l41ab8287r81680aa40281d802@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , "freebsd-current@freebsd.org" , Robert Noland Subject: Re: X11 crash on exit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2010 08:04:23 -0000 > On Wed, Mar 10, 2010 at 10:40 PM, Tim Kientzle wrote: >> Trying to get X up and running on my Aspire One netbook >> and having a couple of problems. Here's the first: >> >> Whenever I exit, the server gets a Signal 11 and crashes ... >> >> FreeBSD 9.0-CURRENT r201154M: Tue Dec 29 09:27:29 PST 2009 GENERIC i386 >> >> xorg.conf is pretty vanilla except for the two monitors: 1600x1200 external >> on the VGA connector and 1024x600 LVDS display. This was autoprobed by the >> server: >> >> Section "Device" >> Identifier "Card0" >> Driver "intel" >> VendorName "Intel Corporation" >> BoardName "Mobile 945GME Express Integrated Graphics Controller" >> BusID "PCI:0:2:0" >> Option "monitor-LVDS" "LVDSMonitor" >> Option "monitor-VGA" "VGAMonitor" >> EndSection Okay, I've updated a bunch of ports and am still seeing the crash. I rebuilt the server with debug symbols and finally got something informative; here's the relevant portion of the backtrace (frame #10 is the signal 11 delivery). #11 0x0819e363 in DeliverPropertyEvent (pWin=0x5a5a5a5a, value=0xbfbfec0c) at rrproperty.c:34 #12 0x0807015d in TraverseTree (pWin=0x28775f80, func=0x819e340 , data=0xbfbfec0c) at window.c:234 #13 0x08070206 in WalkTree (pScreen=0x2871f8c0, func=0x819e340 , data=0xbfbfec0c) at window.c:262 #14 0x0819e521 in RRDeliverPropertyEvent (pScreen=0x2871f8c0, event=0xbfbfec0c) at rrproperty.c:63 #15 0x0819e5a0 in RRDeleteAllOutputProperties (output=0x28778340) at rrproperty.c:81 #16 0x0819d2b7 in RROutputDestroyResource (value=0x28778340, pid=60) at rroutput.c:414 #17 0x0806f3d0 in FreeClientResources (client=0x287180c0) at resource.c:807 #18 0x0806f4e3 in FreeAllResources () at resource.c:824 #19 0x0806bbf0 in main (argc=4, argv=0xbfbfed68, envp=0xbfbfed7c) at main.c:411 As you can see, the main loop is calling FreeAllResources at a time when the Window pointed to by WindowTable[0] has already been freed. I'm running with MALLOC_OPTIONS=J, so the Window structure was filled with 'Z' at that time, leading eventually to this crash when pWin->firstChild was dereferenced. I haven't yet tracked down exactly when the window in question was freed, so I'm not yet sure about the best fix. My current guess: DeleteWindow in dix/window.c should search WindowTable[] to see if the window being deleted is in the window table and remove it if so. I haven't looked carefully enough at the code yet to know whether it suffices to just set the corresponding WindowTable[] entry to NULL. I'll try that and let you know. Cheers, Tim