From owner-freebsd-threads@FreeBSD.ORG Wed May 28 18:29:14 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 4558E37B401; Wed, 28 May 2003 18:29:14 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 552E043FA3; Wed, 28 May 2003 18:29:13 -0700 (PDT) (envelope-from eischen@pcnet.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h4T1TCnb012570; Wed, 28 May 2003 21:29:12 -0400 (EDT) Date: Wed, 28 May 2003 21:29:12 -0400 (EDT) From: Daniel Eischen To: Petri Helenius In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Daniel Eischen cc: David Xu 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: Thu, 29 May 2003 01:29:14 -0000 On Wed, 28 May 2003, Daniel Eischen wrote: > On Wed, 28 May 2003, Petri Helenius wrote: > > > > > > > > >Unfortunatly I have run your test program for five minutes without problem. > > > > > I think we?re getting close. I suspect you didn?t link the binary static? > > > > With same object file and othervise same link line, if I remove -static it runs fine, > > if I link the binary with -static it fails within a first few seconds. > > > > Now, thread guru?s, what happens differently when running statically linked > > binary? It?s compiled and linked and run on the same box than the non-static one. > > What happens is that libkse doesn't make use of spinlocks itself, > unlike libc_r which uses them internally. Spinlocks are not > suppose to be used by applications either, and your application > doesn't use them directly. In this instance, they are only > being used internally by libc. So when the linker resolves > references to _spin[un]lock() in libc, it has already examined > libkse and ends up linking to the null spinlock stubs that > are within libc. I'm not sure why this is, but linking > dynamically doesn't have this problem. > > If you examine the innards of libc_r and libpthread (in > uthread/uthread_init.c and thread/thr_init.c respectively), > you'll see a table of references to work around the static > linking problem. If you apply this patch, it will add > references to spinlocks within the table and things should > work again: Note that if you are using my other spinlock patch (from http://people.freebsd.org/~deischen/kse/spinlock.diffs), that also solves the problem but in a slightly different way. That patch forces the library to reference the spinlock functions (the new spinlock implementation needs some initialization), so the table of references doesn't need to be changed (like the patch in the prior email does). -- Dan Eischen