Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 391795 - [launcher][gtk] Usability: Insufficient error reporting on startup when DISPLAY is not set or not accessible
Summary: [launcher][gtk] Usability: Insufficient error reporting on startup when DISPL...
Status: RESOLVED FIXED
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: Launcher (show other bugs)
Version: 3.8.1 Juno   Edit
Hardware: PC Linux-GTK
: P3 major (vote)
Target Milestone: Kepler M3   Edit
Assignee: Silenio Quarti CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 314849
Blocks:
  Show dependency tree
 
Reported: 2012-10-12 10:38 EDT by Martin Oberhuber CLA
Modified: 2013-11-10 22:32 EST (History)
10 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Oberhuber CLA 2012-10-12 10:38:03 EDT 
+++ This bug was initially created as a clone of Bug #314849 +++

CQ:WIND00108178
CQ:WIND00380449
Build ID: Eclipse Platform 4.2.1 (Juno SR1)

When launching Eclipse on Linux without DISPLAY set, I'm getting this:

> unsetenv DISPLAY
> ./eclipse
Eclipse:
An error has occurred. See the log file
/folk/mober/Ecltest/4.2.1_32/eclipse/configuration/1350051850732.log.

With the logfile contents saying "gtk: no more handles" among some other obscure contents. So the change from bug 314849 has slightly improved things in Eclipse 3.8 but doesn't quite help enough for an end user yet. I'm setting severity MAJOR since it happens relatively easily in a networked multi-host environment to forget setting the display, and as an end user I'm pretty lost in this case.

Expected behavior: 

Print message to stderr, similar to xterm:
xterm Xt error: Can't open display: 
xterm:  DISPLAY is not set

Note that another special case is when the DISPLAY is set but the current user has no permission using it. This happens when using an "ssh -X" session and then becoming root. Here is what xterm does in this case:

> ssh -X szg-tschwarz-lx1
> sudo su -
> xterm
Warning: This program is an suid-root program or is being run by the root user.
The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.
xterm Xt error: Can't open display: %s

I'm hoping that improving this is simple enough to do in SR2.
Comment 1 Martin Oberhuber CLA 2012-10-12 11:02:05 EDT 
CQ:WIND00381930
Comment 3 Thomas Watson CLA 2012-10-16 08:59:45 EDT 
(In reply to comment #0)
> I'm hoping that improving this is simple enough to do in SR2.

Silenio, do you have thoughts here.  Is this something we should consider for Juno SR2?
Comment 4 Silenio Quarti CLA 2012-10-16 13:20:35 EDT 
We changed the GTK initialization call. We need to test this on all GTK platforms (AIX, Solaris, HPUX, etc) before we can consider for 4.2 SR2.  Even then it seems a bit too risky just for better logging.
Comment 5 Martin Oberhuber CLA 2012-10-16 13:49:28 EDT 
I'll check how the new code feels as soon as I can get hold of a Kepler M3 integration build ... should be able to test Linux and Solaris.

Either way, note that this is not just about better logging. It's about either helping the user in an error condition that's not too uncommon, or leaving them clueless...