Date: Fri, 2 Mar 2001 10:06:10 -0500 (EST) From: Peter Dufault <dufault@hda.hda.com> To: hackers@freebsd.org Subject: Re: Stupid debugging pthread question Message-ID: <200103021506.f22F6AL37014@hda.hda.com> In-Reply-To: <200103021305.f22D52P36608@hda.hda.com> from Peter Dufault at "Mar 2, 2001 08:04:52 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> > (gdb) x/s $esp-8 > > 0x826b400 <dtablecount+6528>: "/wd0/B/usr-src/lib/libc_r/uthread/uthread_dup2.c" > > (gdb) > > I guess it is the "thread_fd_lock_debug/_thread_fd_unlock_debug" > calls with __FILE__ that push this on the stack. I'll build a > debuggable libc_r and see I see. Well, of course with the library compiled with -g and without -O the problem went away. However, I do have a call to "dup2" for some threads in a function installed with "pthread_switch_add_np" > #ifdef HAVE_PTHREAD_NP > pthread_switch_add_np(px_switch); > #endif in order to mimic the vxWorks behavior of having a different file 0, 1, and 2 per thread. By disabling this the behavior goes away, apparently what I'm doing is illegal. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval 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?200103021506.f22F6AL37014>