Closed
Bug 36567
Opened 25 years ago
Closed 25 years ago
Starting mozilla in the background failed if there's a setting for stty in the .cshrc/.login file
Categories
(SeaMonkey :: General, defect, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
Future
People
(Reporter: margaret.chan, Assigned: pavlov)
Details
(Keywords: helpwanted)
Attachments
(2 files)
791 bytes,
text/plain
|
Details | |
1.19 KB,
patch
|
Details | Diff | Splinter Review |
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•25 years ago
|
||
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.
Summary: Starting mozilla in the background failed if there's a setting for stty in the .cshrc/.login file → Starting mozilla in the background failed if there's a setting for stty in the .cshrc/.login file
Comment 2•25 years ago
|
||
[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•25 years ago
|
||
[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: <130228@sun.Eng.Sun.COM>
References: <829@eplunix.UUCP>
Reply-To: lm@sun.com (Larry McVoy)
Organization: Sun Microsystems, Mountain View
Lines: 164
From: lm@snafu.Sun.COM (Larry McVoy)
Subject: Re: tcsh and process groups
Date: 13 Jan 90 22:34:37 GMT
In article <829@eplunix.UUCP> das@eplunix.UUCP (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 (415) 336-7627 ...!sun!lm or lm@sun.com
------- End of forwarded message -------
Comment 4•25 years ago
|
||
updating owner. confirming. pav, sspitzer said you might like this one :)
copying syd, akkana, alecf, and sspitzer.
mtchan@eng.sun.com, 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.
Assignee: asadotzler → pavlov
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 5•25 years ago
|
||
Thanks for the update.
Assignee | ||
Updated•25 years ago
|
Keywords: helpwanted
Comment 6•25 years ago
|
||
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
QA Contact: jelwell → doronr
Assignee | ||
Updated•25 years ago
|
Target Milestone: --- → Future
Reporter | ||
Comment 7•25 years ago
|
||
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
Reporter | ||
Comment 8•25 years ago
|
||
Reporter | ||
Comment 9•25 years ago
|
||
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?
Reporter | ||
Comment 10•25 years ago
|
||
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?
Reporter | ||
Comment 11•25 years ago
|
||
Comment 12•25 years ago
|
||
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•25 years ago
|
||
Just got an r=cls@seawood.org from Chris on #mozilla. Margaret, you've got
the a=brendan@mozilla.org. Please check this fix into the tree today when
it's open and green. Thanks.
Reporter | ||
Comment 14•25 years ago
|
||
Code already checked in on 9/14, changing bug status to resolved.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Updated•21 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•