JDK-4374153 : Some graphics don't get drawn when forwarding X11 over ssh (secure shell)
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.2.2,1.3.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris_7,solaris_8
  • CPU: generic,sparc
  • Submitted: 2000-09-26
  • Updated: 2001-01-26
  • Resolved: 2001-01-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.3.1 betaFixed
Related Reports
Duplicate :  
Relates :  
Description
The ssh (secure shell) program establishes an encrypted connection between hosts, and establishes an interactive shell session much like the classic
rsh or rlogin programs.  In addition, it can forward other TCP/IP traffic
between the connected hosts.  In particular, it can easily forward X11
protocal requests, making it appear that the local display actually belongs
to the remote machine.  For example, a session might look something like:

A> ssh B
Welcome to host B...
B> echo $DISPLAY
B:10.0
B> xterm
(xterm pops up on A:0.0 -- B:10.0 is forwarded to A:0.0)

Suppose boths hosts may live behind firewalls that only allow ssh traffic.
Setting DISPLAY on B to A:0.0 would not work since X11 would attempt to
establish a direct connection to A, which would be blocked by the firewall.
Thus, in many security-concious environments, all X11 traffic is transported
over ssh connections.

When a JFC application is run, the main window appears but large portions
of its contents are not drawn at all.  Dragging other windows on top of the
window to attempt to force a refresh does not work.  Running the same
program using a normal DISPLAY setting works fine.  The SwingSet2 demo
from JDK1.3 is a good test case as very little ends up being drawn.

One possibility is that Java2D is arriving at the incorrect conclusion
that the display B:10.0 is local to host B, and attempting to draw without
issuing X commands.  If this is the case, some additional tests must be done
to determine if the display is truly local.

Once this problem is resolved, an ssh test case should be incorporated into
the AWT/Java2D test suites.

The problem was pointed out by Scott Schwartz at Penn State, who has been
unable to work around the problem.

--------------------------
daniel.rice@Eng 2000-09-27

An additional note from Scott:

Here's some more information, which might be useful.

In one xterm:
	A% ssh B

In another:
	A% ssh C
	C% setenv DISPLAY B:9
	C% java ...

In other words, get machine C to display via plain tcp to B, and from
there via the ssh tunnel to A.  The idea is to make sure that C doesn't
think the X server is local, while still going through an ssh tunnel.
And it works.  This suggests that ssh itself isn't buggy with respect
to X11 tunneling, but that java is buggy as it wrongly thinks that
the display is local.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: ladybird-beta FIXED IN: ladybird-beta INTEGRATED IN: ladybird-beta
14-06-2004

PUBLIC COMMENTS Some graphics don't get drawn when forwarding X11 over ssh (secure shell)
10-06-2004

EVALUATION I've mistakenly closed this bug as dup of 4116067. The idea was to close 4398828 as a dup of this one. dmitri.trembovetski@eng 2000-12-18 The bug was reopened on my request. dmitri.trembovetski@eng 2000-12-18 The bug is reproducible with jdk1.3. However, it doesn't on 1.3.1 (as of build 1.3.1-beta-b14). I believe this is due to the fact that we now check if we can use Shared Memory Extension before actually using it. The check was added as a part of fix for Xinerama support (4271351). On 1.4 (build 1.4.0-beta-b49) swing applications crash when run through a ssh connection. The crash happens in solaris dga library code: [1] dga_pix_grab(0x17, 0xa, 0x800002a, 0xa, 0x0, 0xf4ff2000), at 0xf4fdaf40 [2] XDgaGrabDrawable(0x17, 0xf4ff3350, 0x800002a, 0x1c7050, 0xff3e0000, 0xff051ba8), at 0xf4fd6ab4 =>[3] Solaris_DGA_GetLock(env = 0x2b9dd8, display = 0x1c7050, dgaDev = 0x2bd17c, drawable = 134217770U, pSurface = 0x2bd13c, lox = 0, loy = 0, hix = 560, hiy = 300), line 280 in "dgalock.c" [4] X11SD_Lock(env = 0x2b9dd8, ops = 0x2bd0f8, pRasInfo = 0xf407fdc0, lockflags = 2), line 389 in "X11SurfaceData.c" [5] Java_sun_java2d_loops_Blit_Blit(env = 0x2b9dd8, self = 0xf407ffcc, srcData = 0xf407ffc8, dstData = 0xf407ffc4, comp = 0xf407ffc0, srcx = 0, srcy = 0, dstx = 0, dsty = 0, width = 560, height = 300), line 58 in "Blit.c" This nees further inverstigation. We probably need to disable DGA when running on a remote server. As a workaround one can set NO_J2D_DGA to disable DGA use in this case, it works fine then. dmitri.trembovetski@eng 2001-01-25 The crash is indeed a DGA problem. I've filed a bug 4408780 DGA application crashes when run through ssh connection against xserver. In the meantime we'll have to implement some kind of workaround for 1.4. Sure we can set shell env variable NO_J2D_DGA (to, say, 'true') to just turn it off, but it still might be a good idea just to not even try to use DGA if we're run remotely. dmitri.trembovetski@eng 2001-01-26 In response to JDC comments: Note that the crash problem affects only Merlin (1.4) which is still in development, and only present on Solaris Sparc. The original bug (problems rendering through ssh) has been fixed in 1.3.1 (beta is available now). The original bug does not manifest on 1.4 because we don't use Shared Memory Extension. Bug 4408780 DGA application crashes when run through ssh connection has been fixed recently by xserver group. No patches were made, however, since there were no escalations. dmitri.trembovetski@eng 2001-04-02
02-04-2001

WORK AROUND As a workaround for the original problem which is still present in 1.3.0(_01, _02), one can set NO_AWT_MITSHM (say, to 'true') environment variable in your shell before running the application to turn off Shared Memory Extension usage: Something like this: #> setenv NO_AWT_MITSHM true #> java YourApp Note that this workaround is not documented, not supported and is not guaranteed to work in future releases. dmitri.trembovetski@eng 2001-01-26
26-01-2001