Bug 150497 - Hidden setting of DISPLAY causes problems
Summary: Hidden setting of DISPLAY causes problems
Status: RESOLVED WORKSFORME
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Releng (show other bugs)
Version: 3.2   Edit
Hardware: All Linux-GTK
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-Releng-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-07-13 08:26 EDT by Thomas Hallgren CLA
Modified: 2015-03-16 20:48 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Hallgren CLA 2006-07-13 08:26:53 EDT
I recently spent quite some time trying to figure out why I was able to start the Eclipse IDE without problems but was unable to run the jdttext tests from the Eclipse Automated tests suite (see bug #106396).

As it turned out, my problems where caused by the runtests script. It contains an unconditional setting of the DISPLAY variable. Line 4 reads:

  DISPLAY=`$HOST`:0.0;export DISPLAY

In my case, I didn't have the HOST variable set and I would have failed even if that had been the case since my display number was 2.0, not 0.0.

I suggest that you remove the DISPLAY setting completely from the runtests script and instead add a test that prints an error in case DISPLAY is not set.

The current behavior (a somewhat cryptic "No more handles [gtk_init_check() failed]" exception) can be very confusing, especially since you apparently get the same exception for a number of other reasons as well.
Comment 1 David Williams CLA 2015-03-16 20:48:26 EDT
I just happened upon this old bug, and believe it was fixed long ago, but could find no "setting of DISPLAY" in our test codes. That should all be handled by "Hudson" now. There is some stuff in there where we check for "common display managers", and if none found, we start one. This was mostly done, early on, due to Hudson being mis-configured, or something, but that might still cause some people some trouble (such as, if you use one we haven't thought of). 

I'll close as worksforme, since "works now", but I have no idea when "fixed", and apologies it wasn't fixed 8, 9 years ago!?