From owner-freebsd-current Tue Sep 8 04:51:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA15647 for freebsd-current-outgoing; Tue, 8 Sep 1998 04:51:14 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns.tar.com (ns.tar.com [204.95.187.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA15642 for ; Tue, 8 Sep 1998 04:51:12 -0700 (PDT) (envelope-from lists@tar.com) Received: from ppro.tar.com (ppro.tar.com [204.95.187.9]) by ns.tar.com (8.9.1/8.8.7) with SMTP id GAA10364; Tue, 8 Sep 1998 06:51:02 -0500 (CDT) Message-Id: <199809081151.GAA10364@ns.tar.com> From: "Richard Seaman, Jr." To: "HighWind Software Information" Cc: "freebsd-current@FreeBSD.ORG" Date: Tue, 08 Sep 98 06:51:02 -0500 Reply-To: "Richard Seaman, Jr." X-Mailer: PMMail 1.92 For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: libc_r trouble and free() called recursively Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 7 Sep 1998 17:15:04 -0400 (EDT), HighWind Software Information wrote: > > >How bad is it to get this: > > "t_activefile in free(): warning: recursive call." > > bad. It means that you're trying to malloc in a signal handler > (99.9% of the cases), which isn't really allowed... > >I agree. That is a bad thing to do. I just wish the program in question >HAD a signal handler. The only "signal handling" going on would be inside >libc_r.a. > >A quick grep of /usr/src/lib/libc_r/*/*.c CERTAINLY shows "malloc()" >being called. However, I don't know much about when libc_r code runs. >Does this sound like something that could happen? > >Now I'm getting very worried! The pthread scheduler, _thread_kern_sched can get called two ways: 1) When a thread blocks, or 2) When a thread is interrupted by a SIGVTALRM The first thing the scheduler does is check for "dead threads", and cleans them up if it finds them, calling free() in the process. Your previous kernel logs suggest that _thread_kern_sched is called from a SIGVTALRM shortly before it stalls in the accept call. If "dead threads" are processed during this call to _thread_kern_sched you will get a call to free() during the signal handling of SIGVTALRM. I can't explain why you hang at the accept call, nor necessarily why you get "t_activefile in free(): warning: recursive call." However, this would at least explain why you get a free() in a signal handler. Possibly there is a problem in the thread exit and clean up handling, either in your source, or in the pthread library. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message