From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4525 invoked by alias); 7 Jan 2012 01:35:39 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 30095 Received: (qmail 4922 invoked from network); 7 Jan 2012 01:35:37 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at klanderman.net does not designate permitted sender hosts) From: Greg Klanderman To: zsh-workers@zsh.org Subject: Re: zsh hangs loading init files Reply-To: gak@klanderman.net Date: Fri, 06 Jan 2012 20:27:09 -0500 In-Reply-To: (Greg Klanderman's message of "Fri, 06 Jan 2012 20:12:35 -0500") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.17 (linux) References: <20229.54117.22089.85103@gargle.gargle.HOWL> <20120105193518.GE80751@dan.emsphone.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii hmm looks like users/14411 greg >>>>> On January 6, 2012 Greg Klanderman wrote: > yes, thanks. > looks like maybe HASH_DIRS logic was changed and is now stat()ing > every potential executable it finds, whereas it used to only > getdents() on all the dirs in your path. > still haven't found the changeset. > greg >>>>> On January 5, 2012 Dan Nelson wrote: >> In the last episode (Jan 05), Greg Klanderman said: >>> >>> Hi all, >>> >>> I'm in the process of transitioning my work computer from debian 5.0 >>> (lenny) to an Ubuntu variant that Google uses (Goobuntu) and having >>> trouble with newer versions of zsh. While loading my init files, zsh >>> hangs several times for 10-30 sec. This is not happening on 4.3.10 >>> which came with the Goobuntu distribution, or a 4.3.10 which I built >>> from source, but is occurring with 4.3.15 and a cvs checkout in >>> between 4.3.11 and 4.3.12 which I built. I do not see the problem on >>> my old debian box. >>> >>> By putting in some print statements, the first hang seems to occur >>> at a command substitution >>> >>> | case "$(uname -s)" in >>> | ... >>> >>> the last bit of strace up to the hang is: >>> >>> pipe([3, 4]) = 0 >>> fcntl(3, F_DUPFD, 10) = 13 >>> close(3) = 0 >>> fcntl(4, F_DUPFD, 10) = 14 >>> close(4) = 0 >>> rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0 >>> clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f88402d89d0) = 26368 >>> close(14) = 0 >>> fcntl(13, F_GETFL) = 0 (flags O_RDONLY) >>> fstat(13, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 >>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f88402de000 >>> lseek(13, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) >>> read(13, ######## hangs here for 10-30 sec then continues >> zsh isn't hanging; it's just waiting for the output of its forked child >> process (uname). Try adding "-f" to your strace commandline, to follow >> child processes. >> -- >> Dan Nelson >> dnelson@allantgroup.com