From owner-freebsd-ports@FreeBSD.ORG Mon Mar 8 22:59:59 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A0AF16A4CE for ; Mon, 8 Mar 2004 22:59:59 -0800 (PST) Received: from grummit.biaix.org (86.Red-213-97-212.pooles.rima-tde.net [213.97.212.86]) by mx1.FreeBSD.org (Postfix) with SMTP id 7F2AF43D2D for ; Mon, 8 Mar 2004 22:59:58 -0800 (PST) (envelope-from lists-freebsd-hackers@biaix.org) Received: (qmail 10492 invoked by uid 1000); 9 Mar 2004 06:52:29 -0000 Date: Tue, 9 Mar 2004 07:52:29 +0100 From: Joan Picanyol To: freebsd-ports@freebsd.org Message-ID: <20040309065229.GA9722@grummit.biaix.org> Mail-Followup-To: freebsd-ports@freebsd.org, lists-freebsd@biaix.org References: <20040224090105.GA34383@grummit.biaix.org> <1077654347.1751.2.camel@timon.nist> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1077654347.1751.2.camel@timon.nist> User-Agent: Mutt/1.4.1i Subject: Re: XFree86 debugging X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2004 06:59:59 -0000 [please honour Mail-Followup-To:, not subscribed] * Artem Ignatiev [20040224 21:19]: > On Tue, 24.02.2004, at 12:01, Joan Picanyol wrote: > > > > I've found that X gets SIGABRT after (somewhat) long > > inactivity periods. I recompiled with USE_DEBUG=1 hoping to get a > > backtrace, but I can't find the coredump (even though I see 'core > > dumped' in the console). > > > > Where did it go? > try sysctl -w kern.sugid_coredump=1 && sysctl -w > kern.corefile=/usr/tmp/%N.core That did the trick. The backtrace is: (gdb) where #0 0x2825c3ef in kill () from /lib/libc.so.5 #1 0x282510e8 in raise () from /lib/libc.so.5 #2 0x282c6f53 in abort () from /lib/libc.so.5 #3 0x282c588e in tcflow () from /lib/libc.so.5 #4 0x282c60bb in tcflow () from /lib/libc.so.5 #5 0x282c643e in malloc () from /lib/libc.so.5 #6 0x080e17b0 in Xalloc (amount=0) at utils.c:1197 #7 0x080e183a in Xcalloc (amount=67732) at utils.c:1238 #8 0x0809be75 in xf86calloc (sz=1, n=0) at libc_wrapper.c:1778 #9 0x084aa039 in ?? () #10 0x084aa0bc in ?? () #11 0x085e501a in ?? () #12 0x085e513d in ?? () #13 0x085f02cf in ?? () #14 0x085e906c in ?? () #15 0x085e9155 in ?? () #16 0x083e70f4 in ?? () #17 0x0831d053 in ?? () #18 0x0835e2b0 in ?? () #19 0x08366648 in ?? () #20 0x080b75d5 in Dispatch () at dispatch.c:450 #21 0x080c96fb in main (argc=9, argv=0xbfbfee08, envp=0x0) at main.c:438 #22 0x0806b7b9 in _start () (gdb) This is 100% reproducible, with 'aj' options to malloc. How do I find out who is failing to allocate memory and why? What else should I do to debug this? qvb -- pica