From owner-freebsd-current Mon Sep 7 18:18:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA11612 for freebsd-current-outgoing; Mon, 7 Sep 1998 18:18:42 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from awfulhak.org (awfulhak.force9.co.uk [195.166.136.63]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA11601 for ; Mon, 7 Sep 1998 18:18:33 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from woof.lan.awfulhak.org (root@woof.lan.awfulhak.org [172.16.0.7]) by awfulhak.org (8.8.8/8.8.8) with ESMTP id BAA00669; Tue, 8 Sep 1998 01:57:53 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from woof.lan.awfulhak.org (brian@localhost [127.0.0.1]) by woof.lan.awfulhak.org (8.9.1/8.9.1) with ESMTP id CAA03464; Tue, 8 Sep 1998 02:00:04 +0100 (BST) (envelope-from brian@woof.lan.awfulhak.org) Message-Id: <199809080100.CAA03464@woof.lan.awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: HighWind Software Information cc: freebsd-current@FreeBSD.ORG Subject: Re: free() called recursively In-reply-to: Your message of "Mon, 07 Sep 1998 16:29:18 EDT." <199809072029.QAA03642@highwind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Sep 1998 01:59:59 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > How bad is it to get this: > "t_activefile in free(): warning: recursive call." Very. > We are using gcc for C++. One of our test programs which tests code > that currently sends our application out into "la-la land" seems to > print this every few runs. During those runs, it also goes off into > "la-la land". > > "la-la land" == running but going nowhere. ktrace shows nothing, > application only dies with "kill -9". > > We do link against libc_r. I'm wondering if this recursive call thing > is a serious problem and what we can do about it. > > -Rob It's *usually* (sometimes?) caused by code that does complicated things in frequently called signal handlers - perhaps a SIGALRM handler. It *may* happen because of something as simple as a printf() in a SIGUSR1 if the signal happens during a malloc()/free() and printf() feels inclined to do a malloc() or free(). If your program uses frequent signals, you should probably defer the processing 'till after the return of the signal handler to avoid these problems. An example can be found in src/usr.sbin/ppp/sig.c. -- Brian , , Don't _EVER_ lose your sense of humour.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message