freeze on shell suspend/resume in background

RESOLVED INVALID

Status

RESOLVED INVALID
17 years ago
14 years ago

People

(Reporter: rockear-bugzilla, Assigned: Matti)

Tracking

({qawanted})

Trunk
PowerPC
Linux
qawanted

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.1a) Gecko/20020610
BuildID:    2002061108

I run mozilla on a faster computer than mine through a ssh X11 tunnel.  If
mozilla is started in the foreground from an Xterm, suspending the process with
^Z, then resuming it in the background with %1&, causes mozilla to irrevokably
lock up.

Reproducible: Always
Steps to Reproduce:
1. Install moz on a remote host. Make sure X11 forwarding is turned on in sshd.conf.
2. From an Xterm on your host: ssh remote-host mozilla
3. When moz is up, switch back to the Xterm and ^Z
4. Move the suspended moz to the background: %1&
5. Try to switch back into moz.

Actual Results:  Total lock.  Other than the window manager borders, moz's
content area will not repaint, and no events will register.

Xserver: XFree86 4.1.0 debian, on a powerpc 601 (PowerMac 7200/75).  The remote
Mozilla is running on a Red Hat 7.1 x586.  No GNOME or KDE -- a 75 mhz 601 is
too slow! -- just naked X11 and a window manager (FVWM 2.4.7). ssh 3.0.2p1.

Workaround very easy -- don't throw it in the background!
(Assignee)

Comment 1

17 years ago
-> Remote ?
Assignee: Matti → blizzard
Component: Browser-General → X-remote
QA Contact: imajes-qa → blizzard
No, not X remote.  (X-remote means loading web pages through X protocol
commands, i.e. using netscape -remote or mozilla -remote, not displaying to a
remote X server.)
Assignee: blizzard → Matti
Component: X-remote → Browser-General
(Assignee)

Updated

17 years ago
Keywords: qawanted
(Reporter)

Comment 3

17 years ago
Hey folks, I have some additional details about how to trigger this.  I
downloaded the latest nightly build (linux-ppc, 2002061205) and verified that it
does NOT occur when running locally, only when being forwarded over a ssh
connection.  Here's precisely what happens (also with the latest nightly build
on the remote side, linux-i586, 2002061421):

slimedevil 11% ssh nightsider m/mozilla
zsh: suspended  ssh nightsider m/mozilla
slimedevil 12% %1&
[1]  - continued  ssh nightsider m/mozilla
slimedevil 13% scan +bugzil
[1]  + suspended (tty input)  ssh nightsider m/mozilla

The important point is you need to do something, /anything/, in the shell after
moz has been moved to the background, it even interrupted my typing in the above
example.  It's suspended itself, but there's no way to get its attention after
this short of "kill -HUP %1" or destroying the window manually.

Comment 4

17 years ago
do you also see this if you do:

$ ssh nightsider
$ mozilla
^Z
$ %1&
$ exit

I think I've done that a few times myself without problems.  What version of ssh
are you running?  OpenSSH?  What it sounds like is that ssh doesn't like being
put in the background (rather than mozilla).  You might try:

$ ssh nightsider xlock
^Z
$ %1&

that works for me with ssh-3.1.2 (from www.ssh.com)
(Reporter)

Comment 5

17 years ago
OpenSSH 3.0.2p1 on both sides.

Your first suggestion works perfectly, and in view of your explanation, I bet
you're right; ssh just can't cope with being backgrounded.  Didn't know that. 
Darn it, and I was so *sure* I'd found a bug ^_^

Thanks for the help.

Comment 6

17 years ago
$ ssh localhost xclock &  (xclock comes up)
$ (type anything)
[1]  + Suspended (tty input)         ssh localhost xclock

marking INVALID
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.