United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4374153 Some graphics don't get drawn when forwarding X11 over ssh (secure shell)
JDK-4374153 : Some graphics don't get drawn when forwarding X11 over ssh (secure shell)

Details
Type:
Bug
Submit Date:
2000-09-26
Status:
Resolved
Updated Date:
2001-01-26
Project Name:
JDK
Resolved Date:
2001-01-26
Component:
client-libs
OS:
solaris_8,solaris_7,generic
Sub-Component:
2d
CPU:
sparc,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.2.2,1.3.0
Fixed Versions:
1.3.1 (beta)

Related Reports
Duplicate:
Relates:

Sub Tasks

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
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
                                     
2001-01-26
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
                                     
2001-04-02
PUBLIC COMMENTS

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

BugTraq+ Release Management Values

COMMIT TO FIX:
ladybird-beta

FIXED IN:
ladybird-beta

INTEGRATED IN:
ladybird-beta


                                     
2004-06-14



Hardware and Software, Engineered to Work Together