Date: Sat, 18 Aug 2001 19:06:26 -0500 From: "Daniel M . Kurry" <grasshacker@over-yonder.net> To: Michael Class <michaelc@tmbbobmc.bbn.hp.com> Cc: Michael Robinson <robinson@netrinsics.com>, Sheldon Hearn <sheldonh@starjuice.net>, current@FreeBSD.ORG Subject: Re: X in free(): error: recursive call. Message-ID: <20010818190626.B31058@over-yonder.net> In-Reply-To: <20010731090120.X1001-100000@tmbbobmc.bbn.hp.com>; from michaelc@tmbbobmc.bbn.hp.com on Tue, Jul 31, 2001 at 09:13:29AM %2B0200 References: <20010731143505.A771@elephant.netrinsics.com> <20010731090120.X1001-100000@tmbbobmc.bbn.hp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 31, 2001 at 09:13:29AM +0200, some SMTP stream spewed forth:
> 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.
Indeed. It was a Big Fat Mess inside the 3-button emulation code.
libc is innocent, I tell you, innocent! ;-)
> 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
^^^^^^^^^^^
This is the Big Red Truck that I missed during my debugging.
> #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.
Indeed, see above.
> Strange enough, my system at home (with a Matrox G400-Card and Xfree86-4.1.0)
> does not show this symptom.
Indeed, again, I believe it was fixed before that release was, er,
released. This is also fixed in cvs.
XFree86, is zarking cool. You would enjoy the upgrade.
> Michael
Daniel M. Kurry
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?20010818190626.B31058>