From owner-freebsd-current Tue Oct 13 15:17:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA08039 for freebsd-current-outgoing; Tue, 13 Oct 1998 15:17:59 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA08033 for ; Tue, 13 Oct 1998 15:17:50 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.1/8.9.1) id IAA05402; Wed, 14 Oct 1998 08:22:24 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199810132222.IAA05402@cimlogic.com.au> Subject: Re: Recent 3.0's are Depressing In-Reply-To: <199810132212.SAA07558@highwind.com> from HighWind Software Information at "Oct 13, 98 06:12:16 pm" To: info@highwind.com (HighWind Software Information) Date: Wed, 14 Oct 1998 08:22:24 +1000 (EST) Cc: jb@cimlogic.com.au, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG HighWind Software Information wrote: > Hmm. Wouldn't statically linking OUR local libc_r into the application > make it so the changes to libc_r at the customer site not effect us? > Maybe I am missing something. Ah, sorry. Yes _customer_ site changes would be ruled out by that. I thought you were meaning your development system. Are you saying that you can't duplicate the customer's problem on your system? > I suggest that you use CVSup's cvs mode to track the cvs repository and > then checkout sources based on date to isolate which changes have bitten > you. There are test programs in the tree that were submitted by the author > of the signal handling changes. You should try to duplicate your problem > using those tests. Providing a ktrace without a thread status dump is > useless IMO. All that you've shown is that the thread scheduler can't > find a thread to run. The thread status dump should tell you why. I explained > that to you many months ago. > > Can you review how to do that thread status dump again? I apologize for my > ignorance. Send the application a SIGINFO, then look in /tmp/uthread.dump. If necessary, add a diagnostic thread to check that it gets scheduled and to look at the threads that are blocked. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message