From owner-freebsd-threads@FreeBSD.ORG Wed May 28 00:25:02 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9B0637B401 for ; Wed, 28 May 2003 00:25:02 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ED6B43F85 for ; Wed, 28 May 2003 00:25:01 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.9/8.11.4) with ESMTP id h4S7Oxk8074687; Wed, 28 May 2003 10:24:59 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <3ED4644A.6050401@he.iki.fi> Date: Wed, 28 May 2003 10:24:58 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030501 X-Accept-Language: English [en],Finnish [fi] MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: malloc(): error: recursive call X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2003 07:25:03 -0000 Alright, here goes: (it's ugly cut&paste with inadequate includes and stuff but fails as expected) Uncomment the "extra" mutexes and it runs fine. Complied with: gcc -g -O2 -march=pentium -D_REENTRANT -D_THREAD_SAFE -Wall -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Wstrict-prototypes -Wno-format -pedantic -Wno-long-long -c ttest.c gcc -static -g -O2 -march=pentium -D_REENTRANT -D_THREAD_SAFE -Wall -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Wstrict-prototypes -Wno-format -pedantic -Wno-long-long ttest.o -o ttest -lkse libs: # ls -l /usr/lib/libkse* -r--r--r-- 1 root wheel 229156 May 24 14:57 /usr/lib/libkse.a lrwxr-xr-x 1 root wheel 11 May 24 14:57 /usr/lib/libkse.so -> libkse.so.1 -r--r--r-- 1 root wheel 121048 May 24 14:57 /usr/lib/libkse.so.1 -r--r--r-- 1 root wheel 243042 May 24 14:57 /usr/lib/libkse_p.a kernel: FreeBSD kompak.vuokselantie10.fi 5.1-BETA FreeBSD 5.1-BETA #7: Sat May 24 10:49:11 GMT 2003 root@kompak.vuokselantie10.fi:/usr/src/sys/i386/compile/EMTEST i386 # ./ttest free spin free spin free spin free spin free spin free spin free spin free spin free spin free spin free spin alloc spin free spin ttest in free(): error: recursive call Abort (core dumped) and the code: (has more stuff than it needs because it has some debugging built in) #include #include #define SLOTS 100000 void rommon_mutex_lock (pthread_mutex_t *mutex, int line) { int retvalue; int lastline; while (retvalue = pthread_mutex_lock (mutex)) { printf ("%d locking %lx failed, line %d (holder:%d)\n",getpid(),mutex,line,lastline); usleep (100000); } } static pthread_mutex_t foom; static char *foo[SLOTS]; live_poll_sharedmem() { while (1) { int i; printf ("alloc spin\n"); for ( i = 0 ; i < SLOTS; i++) { /* rommon_mutex_lock (&foom,__LINE__);*/ if (!foo[i]) { asprintf (&foo[i],"slot %d",i); } /* pthread_mutex_unlock (&foom);*/ } } } main() { static pthread_t smem_thread; pthread_mutexattr_t attr; int i; pthread_mutexattr_init (&attr); pthread_mutexattr_settype (&attr,PTHREAD_MUTEX_ERRORCHECK); pthread_mutex_init (&foom,&attr); pthread_create (&smem_thread,NULL,&live_poll_sharedmem,0); while (1) { printf ("free spin\n"); for ( i = 0; i < 100000; i++) { /* rommon_mutex_lock (&foom,__LINE__);*/ if (foo[i]) { free (foo[i]); foo[i] = NULL; } /* pthread_mutex_unlock (&foom);*/ } } } Daniel Eischen wrote: >On Wed, 28 May 2003, Petri Helenius wrote: > > > >>>And what does `ldd libnetsnmp.so.x`, `ldd libfoo.y`, show? >>> >>> >>They give empty replies. >> >> >> >>>What is `ldd yourexecutable` show? >>> >>> >>It?s usually linked static but if I remove the -static line it says: >> libnetsnmp.so.5 => /usr/local/lib/libnetsnmp.so.5 (0x2807f000) >> libcrypto.so.3 => /usr/lib/libcrypto.so.3 (0x280fe000) >> libpcap.so.2 => /usr/lib/libpcap.so.2 (0x28209000) >> libkse.so.1 => /usr/lib/libkse.so.1 (0x28225000) >> libc.so.5 => /usr/lib/libc.so.5 (0x28246000) >> >> >> >>>malloc is thread safe and we've been using it fine >>>with all our tests. I suspect you're using another >>>library that is using libc_r or something. >>> >>> >>malloc works for me with for example linuxthreads. So I do believe that >>the the trigger for malloc locking works, however looking at the code, >>spinlocks are implemented differently depending on which thread library is >>linked in. >> >> > >Also, you do need a relatively recent kernel. There are >a couple of flags in each thread's mailbox that the >kernel needs to recognize. This change was committed >to the kernel around April 21, 2003 > > >