Date: Sat, 18 Aug 2001 19:01:48 -0500 From: "Daniel M . Kurry" <grasshacker@over-yonder.net> To: Michael Robinson <robinson@netrinsics.com> Cc: current@freebsd.org Subject: Re: X in free(): error: recursive call. Message-ID: <20010818190148.A31058@over-yonder.net> In-Reply-To: <200107291429.f6TETe100733@netrinsics.com>; from robinson@netrinsics.com on Sun, Jul 29, 2001 at 10:29:40PM %2B0800 References: <200107291429.f6TETe100733@netrinsics.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 29, 2001 at 10:29:40PM +0800, some SMTP stream spewed forth: > I am running -CURRENT as of 2001/01/31 12:00, more or less uneventfully > for the last six months on a Dell 5000e. > > The one problem is that X occasionally dies without coredump or cleanup with > the error 'X in free(): error: recursive call.'. This usually (but not > always) happens while using Mozilla with heavy window creation/deletion and > heavy (dialup) network activity. This has happened under several recent > versions of Mozilla, two different versions of fvwm2, with and without > session managers, and with both X 4.0.3 and 4.1.0. *ding* So I'm not alone on this. I experienced this a while back running XF86 HEAD from cvs. The developers tracked it down to a signal handler calling malloc/free through the 3-button emulation code. You could be experiencing something completely different, but they fixed my particular version of this problem in cvs a couple months ago (I believe). When experiencing the "crash", I would be heavily "clicking", opening/moving/hiding/showing windows. > It took me a while to identify the problem, because it happens infrequently, > unpredicably, and leaves the video drivers in an unusable state (forcing a > blind reboot). I tried linking /etc/malloc.conf to 'A' to get a coredump > from X, but that doesn't work. I found a very short discussion of a related > problem in the -CURRENT mail archives from the beginning of January, but > there wasn't any apparent resolution of the problem. This was discussed on the XFree86 lists, which you probably weren't reading, being using a release. > 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. You /could/ fire up a copy of gdb on the server binary, but I believe there are some messes with the modules XFree86 uses. (Don't take my word for this, I know largely nothing about debugging X.) > 2. Downgrade to -STABLE. The reason I was running -CURRENT originally was > for ACPI support, but Dell has since released an APM-enabled BIOS for > the 5000e, so -CURRENT is no longer a requirement. This seems very much *not* a FreeBSD problem. > 3. Upgrade to current -CURRENT. I don't know if this is such a good idea > judging from mailing list traffic. Same as above, NAFP. > 4. Hang in with the status quo for another couple months until 5.0 is > released, install that, and start back at #1 if that doesn't work. Yet again, NAFP. > Any advice, comments, or suggestions warmly appreciated. Can you run a CVS version of XFree86? I believe this was repaired in one of the more-recent (most-, possibly) 4.x releases. > Thanks. > > -Michael Robinson G'luck, cheers. 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?20010818190148.A31058>