Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!ucbvax!agate!apple!sun-barr!newstop!sun!eureka!argv From: argv%eureka@Sun.COM (Dan Heller) Newsgroups: comp.mail.mush Subject: Re: Mush on Apollos (SR 9.7) Message-ID: <120409@sun.Eng.Sun.COM> Date: 9 Aug 89 18:00:58 GMT References: <8908091029.AA17481@ztivax.uucp> Sender: news@sun.Eng.Sun.COM Reply-To: argv@sun.UUCP (Dan Heller) Lines: 45 In article <8908091029.AA17481@ztivax.uucp> lbo%ztivax@ZTIVAX.SIEMENS.COM (Lothar Borrmann) writes: > - On invoking an editor (eg. by ~e), mush will not be resumed after > termination of the editor subprocess. It simply hangs and has to be killed. > - After invoking some external command, mush will have disappeared and I am > back in my shell again. > I presume that this is a problem of insufficient BSD compatibility of > the Apollo SR 9.7 system (a known problem). The problem sounds suspiciously like your SIGCHLD is broken. I'd be willing to bet that your signal() library is really sys-v based than BSD based. What's happening is that your wait() routine is hanging because the apollo's OS has the same bug that xenix's OS has where if SIGCHLD is set to a signal catcher, then the dead child causes the signal catcher to get called, it calls wait() to pick up the dead child, and the wait() in "pclose()" or in execute.c never returns because it never gets the terminated process. It also doesn't return -1 as it should. I don't remember the exact problem with this -- I wrestled for months trying to get xenix to work properly with respect to wait() and SIGCHLD to no avail. What you might try doing is editing loop.c where SIGCHLD is set to either SIG_DFL for sys-v or sigchldcatcher for BSD by using #ifdef's -- force it to be SIG_DFL and see what happens. Also, before and after you try my suggestion, turn on debugging using the "debug" command. (no args.) Then run ~e and return. You should get a message that pid XXXXX died. If you do, and Mush is still hung, force a core dump using ^\ and look at the stack trace using adb: % adb mush $c (output) ^D % One of the things in the stack should be a call to wait() or something similar. This means that the problem you're having is the one I've described above. Note: the last I checked the xenix documentation, the interplay between wait() and setting the signal handler for SIGCLD does *not* act the way it is documented. In my opinion, the doc is right, but the implementation is wrong. The symptoms you described sound very similar to the xenix problem. dan----- My postings reflect my opinion only -- not the opinion of any company.