From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17576 invoked by alias); 24 Apr 2003 14:45:01 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 17532 invoked from network); 24 Apr 2003 14:45:00 -0000 Received: from unknown (HELO mail.goquest.com) (12.18.108.6) by sources.redhat.com with SMTP; 24 Apr 2003 14:45:00 -0000 Received: (qmail 20363 invoked by uid 0); 24 Apr 2003 14:44:55 -0000 Received: from mszick@goquest.com by mail.goquest.com by uid 502 with qmail-scanner-1.15 (spamassassin: 2.31. Clear:. Processed in 0.83496 secs); 24 Apr 2003 14:44:55 -0000 Received: from unknown (HELO wolf686) (66.90.217.134) by mail.goquest.com with SMTP; 24 Apr 2003 14:44:54 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Michael S. Zick To: Alexandre Oliva , Joe Buck Subject: Re: 3.2.3-pre tarball 2: libjava build still fails on sparc-sun-solaris2.8 Date: Thu, 24 Apr 2003 16:15:00 -0000 Cc: gcc@gcc.gnu.org References: <20030417091616.A11341@synopsys.com> <20030423115153.A8351@synopsys.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <03042409381200.00937@wolf686> Content-Transfer-Encoding: 8bit X-SW-Source: 2003-04/txt/msg01233.txt.bz2 On Wednesday 23 April 2003 05:34 pm, Alexandre Oliva wrote: > On Apr 23, 2003, Joe Buck wrote: > > I realize that getting libtool to work right and portably is a tough job. > > Thanks; it is, indeed :-) I may have stumbled on a BASH behavior that could cause erratic script execution. In brief... While working on a script containing a sequence of shell commands (internal bash commands) that caused BASH to fork multiple threads... Getting totally unexpected behavior, in a seperate term, I attached an: strace -fF -e trace=process -p PID_of_first_term And found that my script was putting BASH into a state where it was doing a "wait4" on a single child when it should have been doing, in effect, a "wait4 ALL" of the child threads it had created. Such a problem could be in any of: BASH - 2.0.5, version 2.05a.0(1)-release Perhaps in the threading: glibc version 2.2.2 Perhaps in the scheduler behavior of the OS: Linux-2.4.20 (2 processor, SMP ) It is a rare, but repeatable "corner case" once you have the situation where, of the multiple threads created, at least one of them has significantly longer execution time than the rest; leading to "out of order" completion. Just a "heads up" that BASH scripts may not be completing things in the order the author has envisioned (coded). Mike