Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 4 Mar 1999 09:09:25 -0600
From:      "Richard Seaman, Jr." <dick@tar.com>
To:        "Russell L. Carter" <rcarter@pinyon.org>
Cc:        current@FreeBSD.ORG
Subject:   SMP Threads (was: Re: SMP and SO5.0)
Message-ID:  <19990304090925.B441@tar.com>
In-Reply-To: <199903040113.SAA17500@psf.Pinyon.ORG>; from Russell L. Carter on Wed, Mar 03, 1999 at 06:13:43PM -0700
References:  <199902171940.OAA69973@y.dyson.net> <199903040113.SAA17500@psf.Pinyon.ORG>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990304090925.B441>