From owner-freebsd-current Thu Mar 4 7: 9:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from ns.tar.com (ns.tar.com [204.95.187.2]) by hub.freebsd.org (Postfix) with ESMTP id 0378514FCA for ; Thu, 4 Mar 1999 07:09:46 -0800 (PST) (envelope-from dick@ns.tar.com) Received: (from dick@localhost) by ns.tar.com (8.9.3/8.9.3) id JAA04934; Thu, 4 Mar 1999 09:09:25 -0600 (CST) (envelope-from dick) Date: Thu, 4 Mar 1999 09:09:25 -0600 From: "Richard Seaman, Jr." To: "Russell L. Carter" Cc: current@FreeBSD.ORG Subject: SMP Threads (was: Re: SMP and SO5.0) Message-ID: <19990304090925.B441@tar.com> References: <199902171940.OAA69973@y.dyson.net> <199903040113.SAA17500@psf.Pinyon.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199903040113.SAA17500@psf.Pinyon.ORG>; from Russell L. Carter on Wed, Mar 03, 1999 at 06:13:43PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Mar 03, 1999 at 06:13:43PM -0700, Russell L. Carter wrote: > > John Dyson extemporised: > > %Julian Elischer said: > %> > %> > %> On Tue, 16 Feb 1999, Luoqi Chen wrote: > %> > You may try my patch at http://www.freebsd.org/~luoqi, which would allow > %> > linux threads to run on SMP. > %> > %> I've gone through these patches and I can see that they are really needed > %> for SMP where address spaces are shared. > %> > %I agree -- a per-cpu page directory per multithreaded process is the way that > %I had implemented. Excellent!!! > % > > So I tried these out. The examples work in the linuxthreads dir but many > other things do not. For instance, > > Built debug ACE+TAO with egcs-2.91.62, March 2 -current, newest > LinuxThreads port. Uniprocessor has no errors. SMP fails, for instance: > > rcarter@mazatzal:~/ace/ACE_wrappers/tests [82] ./TSS_Test > TSS_Test in malloc(): warning: recursive call. > TSS_Test in malloc(): warning: recursive call. > Abort trap (core dumped) > rcarter@mazatzal:~/ace/ACE_wrappers/tests [83] gdb TSS_Test -core > TSS_Test.coreGDB is free software and you are welcome to distribute copies of > it > under certain conditions; type "show copying" to see the conditions. > There is absolutely no warranty for GDB; type "show warranty" for details. > GDB 4.16 (i386-unknown-freebsd), > Copyright 1996 Free Software Foundation, Inc... > Core was generated by `TSS_Test'. > Program terminated with signal 6, Abort trap. > Reading symbols from /home/rcarter/ace/ACE_wrappers/ace/libACE.so...done. > Reading symbols from /usr/local/lib/liblthread.so.0...done. > Reading symbols from /usr/lib/libm.so.2...done. > Reading symbols from /usr/lib/libc.so.3...done. > Reading symbols from /usr/libexec/ld-elf.so.1...done. > #0 0x18243bf4 in sched_yield () > (gdb) where > #0 0x18243bf4 in sched_yield () > #1 0x181eb051 in sched_yield () at sched.c:58 > #2 0x181eac79 in _spinlock (lck=0x18281738) at spinlock.c:88 > #3 0x18278a02 in free () > #4 0x181a8765 in __builtin_delete (ptr=0x8054170) > #5 0x804ada5 in worker (c=0x64) at TSS_Test.cpp:222 > #6 0x180fc4e2 in ACE_Thread_Adapter::invoke (this=0x8051540) at OS.cpp:2075 > #7 0x180fc556 in ace_thread_adapter (args=0x8051540) at OS.cpp:2194 > #8 0x181ebe8c in pthread_start_thread (arg=0xeb5ffd04) at manager.c:160 > #9 0x181ec49d in _clone () at clone.S:1 > #10 0xffffffff in ?? () > #11 0x1805ec5c in .curbrk () > Cannot access memory at address 0xf9dc. Comments (but no solution): 1) gdb is tricky to use with threads. What you see is not always where you are. It doesn't always follow the threads very well, if at all. 2) AFAIK, there are only two reasons you should ever see the "malloc(): warning: recursive call" message. One reason is that the libc global variable __isthreaded is not set. I don't think this is the case here, since the gdb trace seems to show _spinlock being called within free(). This would not happen if __isthreaded is not set. 3) The other reason for the warning is that malloc/free have been called recursively within the same thread. AFAIK, this can only happen if malloc/free are called within a signal handler (which is an error), and one of malloc/free is interrupted by a signal. Looking briefly at the ACE TSS_Test code, I suspect that the signal handler calls free(). 4) I'm not sure what the real problem is, whether it is a bad signal handler, or more likely, the real problem is whatever generated the signal within malloc/free, and the bad signal handler is a misdirect. -- 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-current" in the body of the message