Date: Sun, 9 May 1999 09:14:15 -0500 From: "Richard Seaman, Jr." <dick@tar.com> To: kip@lyris.com Cc: hackers@freeBSD.org Subject: Re: problems with recursion in libc_r Message-ID: <19990509091415.E6953@tar.com> In-Reply-To: <Pine.SOL.4.05.9905071944380.4894-100000@luna>; from kip@lyris.com on Fri, May 07, 1999 at 07:50:33PM -0700 References: <Pine.SOL.4.05.9905071944380.4894-100000@luna>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 07, 1999 at 07:50:33PM -0700, kip@lyris.com wrote: > I am running FreeBSD 3.1 STABLE. There appears to be a problem with > wrterror and wrtwarning from malloc/free when using threads because it > calls _thread_fd_lock_ which in turn calls malloc etc. > I have made a stopgap fix to the two functions, by having them return > before calling write. I hope that someone else will have a more > intelligent fix. A bit of hackery that might help would be to call _thread_fd_table_init() for fd's 0 to 2 when libc_r starts up (ie. in _thread_init()) There is also a deeper issue, which is that libc (and libc_r) need multpile versions of some syscalls, such as write(). There needs to be the "pure syscall", which is libc is _write(), and in libc_r is _thread_sys_write(). (Ultimately it would be nice if both libc and libc_r used the same naming convention). Then there needs to be something like _libc_write(), which is the version of write used internally to libc (and libc_r). Then finally there needs to be the version exported to user apps, write(). Maybe there even needs to be more layers. GNU glibc has at least 4 layers, I think. The reason for the multiple layers is that more complex apps, like threads libraries, end up needing to "wrap" the pure syscall to implement things like fd locking (libc_r), or pthread_cancellation points (libc and libc_r). It is not always correct to use the final wrapped versions of the syscalls within libc or within threads libraries themselves. Then, an internal libc function like malloc would call the appropriate version of write() that didn't have the potential to recurse. > > A partial trace follows: > #0 malloc (size=76) at /usr/src/lib/libc_r/../libc/stdlib/malloc.c:1066 > #1 0x82ee633 in _thread_fd_table_init (fd=2) at > /usr/src/lib/libc_r/uthread/uthread_fd.c:75 > #2 0x82eea9b in _thread_fd_lock (fd=2, lock_type=2, timeout=0x0) at > /usr/src/lib/libc_r/uthread/uthread_fd.c:272 > #3 0x82e9aa9 in write (fd=2, buf=0xefbfdc27, nbytes=5) at > /usr/src/lib/libc_r/uthread/uthread_write.c:58 > #4 0x830f370 in wrtwarning (p=0x8399c81 "recursive call.\n") at > /usr/src/lib/libc_r/../libc/stdlib/malloc.c:292 > #5 0x8310050 in malloc (size=76) at > /usr/src/lib/libc_r/../libc/stdlib/malloc.c:1069 > #6 0x82ee633 in _thread_fd_table_init (fd=2) at > /usr/src/lib/libc_r/uthread/uthread_fd.c:75 > #7 0x82eea9b in _thread_fd_lock (fd=2, lock_type=2, timeout=0x0) at > /usr/src/lib/libc_r/uthread/uthread_fd.c:272 > #8 0x82e9aa9 in write (fd=2, buf=0xefbfdc27, nbytes=5) at > /usr/src/lib/libc_r/uthread/uthread_write.c:58 > #9 0x830f370 in wrtwarning (p=0x8399b95 "junk pointer, too high to make > sense.\n") at /usr/src/lib/libc_r/../libc/stdlib/malloc.c:292 > #10 0x830ffb9 in ifree (ptr=0x863c0a0) at > /usr/src/lib/libc_r/../libc/stdlib/malloc.c:1043 > #11 0x8310151 in free (ptr=0x863c0a0) at > /usr/src/lib/libc_r/../libc/stdlib/malloc.c:1097 > #12 0x82e2df1 in __builtin_vec_delete (ptr=0x863c0a0) > > > -Kip > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990509091415.E6953>