Date: Tue, 31 Jul 2001 09:13:29 +0200 (CEST) From: Michael Class <michaelc@tmbbobmc.bbn.hp.com> To: Michael Robinson <robinson@netrinsics.com> Cc: Sheldon Hearn <sheldonh@starjuice.net>, <current@FreeBSD.ORG> Subject: Re: X in free(): error: recursive call. Message-ID: <20010731090120.X1001-100000@tmbbobmc.bbn.hp.com> In-Reply-To: <20010731143505.A771@elephant.netrinsics.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello,
I was running in the same problem early this year. Probably you
have found my mails in the archive. Unfortunately I was not able
solve the problem. I am running now 3.3.6 on my laptop (which
furtunately supports the graphics chips that my laptop has).
Just as a datapoint: My understanding of the problem is that it
is really a problem of XFree (as opposed to FreeBSD) There seems
to be a situation where malloc is called within a signal
handler. It was explained to me that malloc cannot be recursively
called. Therefore, if a signal interrupts Xfree when it is in the
libc *alloc-functions, this can crash the server.
The following trace shows this scenario:
#0 0x2820a9e8 in kill () from /usr/lib/libc.so.5
#1 0x2825bb3d in abort () from /usr/lib/libc.so.5
#2 0x2825a682 in isatty () from /usr/lib/libc.so.5
#3 0x2825a6b0 in isatty () from /usr/lib/libc.so.5
#4 0x2825b6a6 in malloc () from /usr/lib/libc.so.5
#5 0x80d19ff in Xalloc (amount=16) at utils.c:1225
#6 0x80cc30c in TimerSet (timer=0x0, flags=0, millis=50, func=0x8788ef0,
arg=0x88a0b00) at WaitFor.c:744
#7 0x87890fa in ?? ()
#8 0x878927d in ?? ()
#9 0x8788bf0 in ?? ()
#10 0x807da23 in xf86SigioReadInput (fd=7, closure=0x88a0b00)
at xf86Events.c:1039
#11 0x8093d48 in xf86SIGIO (sig=23) at sigio.c:99
#12 0xbfbfffac in ?? ()
#13 0x2825b1b0 in isatty () from /usr/lib/libc.so.5
#14 0x2825b901 in realloc () from /usr/lib/libc.so.5
#15 0x80d1b18 in Xrealloc (ptr=0x8eb3000, amount=4096) at utils.c:1322
#16 0x80ceef4 in StandardReadRequestFromClient (client=0x8a0d100) at io.c:403
#17 0x80ac00c in Dispatch () at dispatch.c:438
#18 0x80bc395 in main (argc=3, argv=0xbfbffdc0, envp=0xbfbffdd0) at main.c:439
#19 0x806b31d in _start ()
My understanding is that the problem is with XFree using malloc in a
signal-handler.
Strange enough, my system at home (with a Matrox G400-Card and Xfree86-4.1.0)
does not show this symptom.
Michael
On Tue, 31 Jul 2001, Michael Robinson wrote:
> On Sun, Jul 29, 2001 at 04:38:06PM +0200, Sheldon Hearn wrote:
> > On Sun, 29 Jul 2001 22:29:40 +0800, Michael Robinson wrote:
> > > I'd like to get advice on which of the following courses of action to take:
> > >
> > > 1. Isolate and fix the problem. I would need some help here.
> >
> > Try a better-proven release of XFree86, namely 3.3.6.
>
> Based on my preliminary efforts to isolate the problem, it seems pretty
> clear that A) the code path required to reach the error is not exposed by
> the malloc API to applications (after all, how could an application call
> "free" recursively?), and B) it likely has something to do with an overlooked
> race condition in the thread safety retrofit of libc late last year.
>
> But, as was mentioned previously, XFree86 3.3.6 doesn't have the required
> chip support for the Dell 5000e, so that's not an option, regardless.
>
> I welcome further suggestions, though.
>
> -Michael Robinson
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
>
>
___________________________________________________________________________
Michael Class E-Mail: michael_class@gmx.net
E-Business Solution Division
___________________________________________________________________________
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010731090120.X1001-100000>