Closed Bug 151737 Opened 23 years ago Closed 23 years ago

freeze on shell suspend/resume in background

Categories

(SeaMonkey :: General, defect)

PowerPC
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: rockear-bugzilla, Assigned: Matti)

Details

(Keywords: qawanted)

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!
-> 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
Keywords: qawanted
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.
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)
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.
$ ssh localhost xclock & (xclock comes up) $ (type anything) [1] + Suspended (tty input) ssh localhost xclock marking INVALID
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.