From owner-freebsd-questions Wed Oct 4 20:22:15 1995 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAB15767 for questions-outgoing; Wed, 4 Oct 1995 20:22:15 -0700 Received: from mail.telstra.com.au (mail.telstra.com.au [192.148.160.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA15760 for ; Wed, 4 Oct 1995 20:22:06 -0700 Received: from mail_gw.fwall.telecom.com.au(192.148.147.10) by mail via smap (V1.3) id sma022426; Thu Oct 5 13:16:51 1995 Received: from cdn_mail.dn.itg.telecom.com.au(144.135.109.134) by mail_gw.telecom.com.au via smap (V1.3) id sma009311; Thu Oct 5 13:15:35 1995 Received: from rodin.cssc-syd.tansu.com.au (rodin.cssc-syd.tansu.com.au [149.135.252.15]) by cdn_mail.dn.itg.telecom.com.au (8.6.11/8.6.9) with ESMTP id NAA27781; Thu, 5 Oct 1995 13:15:33 +1000 Received: from crab.cssc-syd.tansu.com.au (crab.ind.tansu.com.au [149.135.100.23]) by rodin.cssc-syd.tansu.com.au (8.6.11/8.6.9) with ESMTP id NAA06279; Thu, 5 Oct 1995 13:15:09 +1000 Received: from kiwi.cssc-syd.tansu.com.au (raoul@kiwi.cssc-syd.tansu.com.au [149.135.104.48]) by crab.cssc-syd.tansu.com.au (8.6.9/8.6.9) with ESMTP id NAA13888; Thu, 5 Oct 1995 13:15:08 +1000 Received: (raoul@localhost) by kiwi.cssc-syd.tansu.com.au (8.6.9/8.6.9) id NAA27004; Thu, 5 Oct 1995 13:15:07 +1000 Message-Id: <199510050315.NAA27004@kiwi.cssc-syd.tansu.com.au> Subject: Re: gdb problem? libraries, perhaps? (RESOLVED!!!) To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Thu, 5 Oct 1995 13:15:07 +1000 (EST) Cc: raoul@cssc-syd.tansu.com.au, freebsd-questions@freebsd.org In-Reply-To: <199510050226.TAA14639@aslan.cdrom.com> from "Justin T. Gibbs" at Oct 4, 95 07:26:54 pm From: raoul@cssc-syd.tansu.com.au (Raoul Golan) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2272 Sender: owner-questions@freebsd.org Precedence: bulk > > > >On FreeBSD, on the other hand, I have csh as my default, and > >"exec /usr/local/bin/zsh" on my .cshrc. With this setup gdb > >crashes since gdb's fork executes .cshrc. > > > >Something's different about the two gdb's, but I'm not sure > >what. > > > >Raoul > > Did you recently upgrade your kernel without rebuilding gdb? The > proc structure was changed a little while back and you will need > to rebuild gdb for it to pick it up. You may have to rebuild > libkvm too. > I've finally got to the bottom of all this. The result is that csh and gdb can make a dangerous combination together. The answer to your question is no. I'm using the same kernel, and the same gcc/gdb as comes with the 2.0.5-RELEASE CD. I'm sure that if you set your default shell to csh, and put in "exec /usr/local/bin/zsh" as the last line of .cshrc as well, then gdb will crash on you, too. Even rebuilding gdb does not help (something I've already tried). I haven't rebuilt kvm, but I doubt it would make a difference. The problem does not appear to be how it's built, but rather how the gdb forks a shell in order to exec the test binary, and what happens when that shell is csh. You see, csh will always execute .cshrc on startup, regardless on whether it's interactive or not. On the other hand, for instance, zsh will only execute .zshrc on *interactive* shells. This means that if your .cshrc has a line saying "exec blah", then invoking "csh filename" will NOT mean executing "filename", but rather "blah" instead. I had "exec /usr/local/bin/zsh" in my .cshrc, so you can see the problem. Yes, you can all shoot me. gdb will fork a shell in order to run its test binary. If that shell is csh, and .cshrc has an "exec blah" line, then gdb is in trouble. It will be forking "blah" instead of its test binary. Is all of this clear? None of this will happen with zsh. It looks very much like a generic gdb problem which appears when combined with csh. I just wish that gdb could be more "user friendly" in giving proper diagnostics or warnings. FreeBSD is completely innocent of all this! I know I can change my default shell rather than having that exec in my .cshrc - but I had it that way since I didn't expect it to cause any problems!