Re: X in free(): error: recursive call.
On Sat, Aug 18, 2001 at 07:01:48PM -0500, Daniel M . Kurry wrote: 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. For the archives, my final resolution of this can be found in ports/29982. http://www.freebsd.org/cgi/query-pr.cgi?pr=29982 -Michael Robinson To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: _sigprocmask in malloc.c causes full file table?
On Sun, Aug 12, 2001 at 10:29:53AM -0400, Daniel Eischen wrote: sigprocmask() behaves the same as pthread_sigmask(). pthread_sigmask() needs to obtain the current thread. In obtaining the current thread, the threads library must be initialized. In initializing the threads library malloc() is called. Wash, rinse, repeat. We have a winner. This is the top of the (very long) call stack from the mozilla core file (which I admittedly should have examined earlier): #11913 0x2863ebda in _thread_init () from /usr/lib/libc_r.so.5 #11914 0x2863e7a3 in _get_curthread () from /usr/lib/libc_r.so.5 #11915 0x28633539 in pthread_sigmask () from /usr/lib/libc_r.so.5 #11916 0x2863f250 in sigprocmask () from /usr/lib/libc_r.so.5 #11917 0x286c9db5 in malloc () from /usr/lib/libc.so.5 #11918 0x2863a980 in _pq_alloc () from /usr/lib/libc_r.so.5 #11919 0x2863ebda in _thread_init () from /usr/lib/libc_r.so.5 #11920 0x2863e7a3 in _get_curthread () from /usr/lib/libc_r.so.5 #11921 0x28633539 in pthread_sigmask () from /usr/lib/libc_r.so.5 #11922 0x2863f250 in sigprocmask () from /usr/lib/libc_r.so.5 #11923 0x286c9db5 in malloc () from /usr/lib/libc.so.5 #11924 0x2863a980 in _pq_alloc () from /usr/lib/libc_r.so.5 #11925 0x2863ebda in _thread_init () from /usr/lib/libc_r.so.5 #11926 0x2863c063 in pthread_mutex_lock () from /usr/lib/libc_r.so.5 #11927 0x2861556d in __register_frame_info () from /usr/lib/libstdc++.so.3 #11928 0x28662fa2 in _init () from /usr/lib/libc.so.5 #11929 0x2866062d in _init () from /usr/lib/libc.so.5 #11930 0x2806de10 in _rtld () from /usr/libexec/ld-elf.so.1 So, in answer to the question, am I doing something boneheaded, or is this an undocumented subtle interaction, I'll give partial credit to both. Thank you very much for your assistance. -Michael Robinson To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: X in free(): error: recursive call.
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 [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
X in free(): error: recursive call.
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. 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. 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. 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. 3. Upgrade to current -CURRENT. I don't know if this is such a good idea judging from mailing list traffic. 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. Any advice, comments, or suggestions warmly appreciated. Thanks. -Michael Robinson To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
