36567 - Starting mozilla in the background failed if there's a setting for stty in the .cshrc/.login file

Status: RESOLVED FIXED

(SeaMonkey :: General, defect, P3)

Description

[Margaret Chan]

Overview Description:  If I have any of the following lines in my .cshrc file:
			  stty erase ^\? OR stty -tabs, mozilla will not
                          start up in the background (i.e., mozilla&) 

Steps to Reproduce: 
1) Using csh on Solaris
2) Put either "stty erase ^\?" OR "stty -tabs" in the .cshrc
3) Source the file (i.e., source .cshrc)
4) Start up mozilla in the background (./mozilla&)

Actual Results:  
% ./mozilla&
[4] 15746
<image>/net/tuffy/export/home0/MOZBUILD/GNU/netscape6-PR1/package %
.//run-mozilla.sh ./mozilla-bin
MOZILLA_FIVE_HOME=/net/tuffy/export/home0/MOZBUILD/GNU/netscape6-PR1/package
 
LD_LIBRARY_PATH=/net/tuffy/export/home0/MOZBUILD/GNU/netscape6-PR1/package:/usr/dt/lib:/opt/SUNWspro/lib:SUNTOOLS_LIB:/home/mtchan:/home/mtchan/mozilla/libs/lib:/usr/dist/pkgs/socks,v1.0/lib
       SHLIB_PATH=/net/tuffy/export/home0/MOZBUILD/GNU/netscape6-PR1/package
          LIBPATH=/net/tuffy/export/home0/MOZBUILD/GNU/netscape6-PR1/package
      MOZ_PROGRAM=./mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=

[4]  + Stopped (tty output) ./mozilla

Nothing comes up.

Expected Results: 
The Profile Manager/the browser should come up

Reproducibility:
Reproducible on demand

Build Date & Platform Bug Found: 
My own build of the Beta1 source using WS5.0 compiler on my Solaris 2.7 machine.
The problem should not be OS version/compiler version specific.

Additional Builds and Platforms Tested On: 
The problem does not occur on Linux.

Additional Information: 
None

Comment 1

[Asa Dotzler [:asa]]

leaf, does this look like a Build Config issue.  Do you want it? It is reported 
from NS6PR1 but is probably valid on moz as well.

Comment 2

[Rich Burridge]

[richb - 4/21/00]
I have a hard time believing this is a build issue. My guess is that some
ioctl call is not being done, or is being incorrectly done at initialisation
time in some Solaris specific code, but it's only a guess.

Comment 3

[Rich Burridge]

[richb - 4/21/00]
I have a little more on this. It actually occurs in the run-mozilla.sh
script. Here's the last few lines:

...
+ moz_run_program 
prog=mozilla-bin
+ [ ! -x mozilla-bin ] 
+ which md5sum 

[2]  + Stopped (tty output) sh -x run-mozilla.sh

I've been digging through my old mail/news archives and found this from about
ten years ago. It might bear some relevance. It looks like a little bit of
shell wizardry is needed. Any shell wizards in Netscape/Mozilla?

------- Start of forwarded message -------
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Newsgroups: comp.unix.wizards
Message-ID: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail] (Larry McVoy)
Organization: Sun Microsystems, Mountain View
Lines: 164
From: [e-mail] (Larry McVoy)
Subject: Re: tcsh and process groups
Date: 13 Jan 90 22:34:37 GMT

In article <[e-mail]> [e-mail] (David Steffens) writes:
>Late last summer (August?) there was a discussion in this group
>about how csh/tcsh handles process groups.  The problem as I remember
>was that under SunOS on a SUN4, you don't want to use vfork().
>But vfork() enforces a certain processing order which is absent otherwise.
>So if you don't use vfork(), you end up with the following annoyance:
>	% egrep foo bar.c | less
>	Stopped (tty output)
>	%
>
>The discussion seemed to revolve around how process groups are set up
>for pipelines.  Chris Torek (I think) said that there was a race.
>I don't remember whether it was ever explained why this problem
>doesn't occur with the SunOS4.0 version of csh.

This is a nifty little problem.  There are actually several potential
problems here (and they get worse under posix).  They are not specific
to csh, any job control cognizant shell can have these problems.

Here's the deal.  There are several terms: 

controlling terminal (tty):
	This is an open tty device that is distinguished by its association
	to a particular set of processes (session in posix).  In posix,
	there is the concept of a session leader; that is the process that
	established the association (usually via open(2)).  An easy way to
	see if you have a controlling terminal is to open /dev/tty; the
	open will fail if you don't.

controlling terminal's process group (tty's pgrp):
	If a tty is a controlling terminal then it has an associated
	process group.  When the session leader gets the tty the tty's
	pgrp is set to the session leaders pgrp.

session:
	A group of process groups.  Usually associated with a tty but
	not necessarily so.  Never associated with more than one tty.

foreground process group:
	The process group who's value matches the tty's pgrp.  (This is
	how tty signals work; the tty driver sees the control char
	in the input stream, recognizes it as one of the specials, and
	sends off a signal to its pgrp.)

tuple [pid, pgid, sid]:
	This is a notation I use when describing this sort of thing.
	pid == process id, pgid = process group id, sid == session id.  
	A session leader looks like [100, 100, 100].

(Note: I probably did a so-so job on these terms; the POSIX 1003.1
standard defines these and more in a very nice way.  They also do
a nice job of explaining job control).

Now that that's out of the way, we can get down to business.  When
a shell forks a pipeline, what happens?  It usually looks something
like:

	signal(SIGCHLD, reaper);
	pgrp = 0;
	for i in <pipe components> {
		if (tmp = [v]fork()) {
			if (!pgrp) {
				pgrp = tmp;
				ioctl(0, TIOCSPGRP, &pgrp);
			}
			setpgrp(tmp, pgrp);	/* changing child's */
		} else {
			/* set up pipe file desc */
			/* set up signals */
			/* whatever */
			exec(i);
		}
	}
	/* shell waits for all kids here */

There are several problems with this:

(1) ioctl+setpgrp/exec race.  In order for things to be "right", the 
    child process should have the tty (ie, the tty's pgrp should ==
    child's pgrp) and the child should be in its own pgrp (child's pgrp
    != shell's pgrp) before the exec.  Since not all systems have
    vfork(), some shells use fork().  There is no guarantee which half
    of the fork starts first.  If the parent keeps going all is well;
    if the child goes first there is trouble (if it produces output or
    trys an ioctl() on the tty, it will be stopped if it is not the
    foreground process group [well, in many cases it will be stopped;
    there are exceptions]).

(2) Suppose we did the following:
    
    $ echo foo | cat 

    And we started from a shell that was [100, 100, 100]; the echo is
    process 200, and the cat is 201.  We want things to look like

    [100, 100, 100]				tty's pgrp: [200]

    [200, 200, 100] | [201, 200, 100]

    Suppose that we fork the echo, it runs, exits, and is reaped (SIGCHLD),
    all before we fork the cat. (This can happen.)  POSIX has a restriction 
    that says when you create a process group it has to be the same value
    as the processes pid.  Other than that, the only way to change your
    process group is to join an existing process group (white lie: calling
    setsid() also changes your pgrp if it succeeds).  If the echo is gone,
    the setpgrp() for the cat will fail because pgrp 200 doesn't exist 
    anymore.

(3) It is also possible that a stupid shell would fork all the processes
    and then set up the tty and pgrp's.  Suppose that we have the same echo
    cat example.  Suppose that the shell starts working backwards; it
    will try to do setpgrp(201, 200) before setpgrp(200, 200).

Fixes:

(1) For the race, the easiest thing to do is to duplicate the code
    in the child so:

	signal(SIGCHLD, reaper);
	pgrp = 0;
	first = 1;
	for i in <pipe components> {
		if (tmp = fork()) {
			if (first) {
				first = 0;
				pgrp = tmp;
				ioctl(0, TIOCSPGRP, &pgrp);
			}
			setpgrp(tmp, pgrp);	/* changing child's */
		} else {
			if (first) {
				pgrp = getpid();
				setpgrp(pgrp, pgrp);
				ioctl(0, TIOCSPGRP, &pgrp);
			} else {
				setpgrp(0, pgrp);
			}
			/* set up pipe file desc */
			exec(i);
		}
	}

    Then it doesn't matter who gets there first.  The vfork() people should
    do this too - depending on vfork() semantics is a kludge (in spite of the
    fact that I tried to convince Guy otherwise years ago.  Sigh.)

(2) The easy fix to this is to have the shell block SIGCHLD while forking
    off the kids.  If the reap doesn't happen until you are done, all is
    well (well, it should be OK.  This assumes that process groups live
    after the process exits until it is reaped.  This is not the case in
    current SunOS and probably BSD implementations; I had to fix it for
    SunOS 4.1).

(3) In the immortal words of Rob Gingell: "Don't do that."  That's way too
    long to wait to set things up and I can't think of a reason why you 
    would need to set them up in reverse order (there may be one though:
    the shell may choose a different method of pipelining where the
    first process forked forks the next and so on.  There are several
    variations on this and it's not impossible that someone can come up 
    with a legitimate example that won't work.)
- ---
What I say is my opinion.  I am not paid to speak for Sun, I'm paid to hack.

Larry McVoy, Sun Microsystems     [phone]       ...!sun!lm or [e-mail]
------- End of forwarded message -------

Comment 4

[Asa Dotzler [:asa]]

updating owner. confirming.  pav, sspitzer said you might like this one :)  
copying syd, akkana, alecf, and sspitzer.  
                                                              
[e-mail], I'm updating your Bugzilla permissions so that your bugs 
start out as New rather than Unconfirmed.  This will also allow you to edit all 
fields of any bugs.  

Comment 5

[Margaret Chan]

Thanks for the update.

Comment 6

[Asa Dotzler [:asa]]

Sorry for the spam.  New QA Contact for Browser General.  Thanks for your help
Joseph (good luck with the new job) and welcome aboard Doron Rosenberg

Comment 7

[Margaret Chan]

Looking at this problem a little bit more.  If I have stty set in my .cshrc,
simply execute the which command in the background will trigger this problem:

<boxelder>/home/mtchan % which md5sum&
[3] 1391
<boxelder>/home/mtchan % 
[3]  + Stopped (tty output) which md5sum

Comment 8

[Margaret Chan]

Attachment: Replace the "which" command with "type"

Comment 9

[Margaret Chan]

I have just attached a possible solution.  I have bypassed the usage of the
which command in the run-mozilla.sh script for Solaris.  Instead I use the
born/korn shell command, type.  Understanding that the command does not exist on
Linux, I have default to use the which command if the type command is not found.
I have tested it on Solaris, but not yet on other Unix platforms.  I plan to do
it when I get to that.  It is not the most elegant solution, but it seems to
work.  Any comments on this?

Comment 10

[Margaret Chan]

I have tested the patch on a linux box, it's working fine;
and it also seemed to work for John Gaunt (jgaunt@netscape) on his
HPUX.  Can someone review (r=) and approve (a=) this for me please?

Comment 11

[Margaret Chan]

Attachment: cvs diff -u output for the same fix

Comment 12

[Brendan Eich [:brendan]]

Adding blizzard and pavlov, hoping they give an r=.  If so, a=brendan.  It all 
looks ok to me (an old Unix and sh hacker) but I haven't tried it.

/be

Comment 13

[Rich Burridge]

Just got an r=[e-mail] from Chris on #mozilla. Margaret, you've got
the a=[e-mail]. Please check this fix into the tree today when 
it's open and green. Thanks.

Comment 14

[Margaret Chan]

Code already checked in on 9/14, changing bug status to resolved.