Date: Sun, 9 May 1999 18:26:11 -0700 (PDT) From: <kip@lyris.com> To: "Richard Seaman, Jr." <dick@tar.com> Cc: hackers@freeBSD.org Subject: Sorry and Re: problems with recursion in libc_r Message-ID: <Pine.SOL.4.05.9905091820400.16701-100000@luna> In-Reply-To: <19990509091415.E6953@tar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I just want to let you know how much I appreciate your getting back to me. I am not sure I conveyed that in my last message. It is not false flattery when I say that I appreciate the quality of FreeBSD. I work with both Linux and FreeBSD everyday, and the difference in the quality of your implementation and theirs is not trivial. Thanks. -Kip On Sun, 9 May 1999, Richard Seaman, Jr. wrote: > 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?Pine.SOL.4.05.9905091820400.16701-100000>