| Summary: | [launcher][gtk] Usability: Confusing errors on startup or SEGFAULT when DISPLAY is not set correctly | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Martin Oberhuber <mober.at+eclipse> |
| Component: | Launcher | Assignee: | Project Inbox <equinox.launcher-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | aniefer, david_williams, eclipse.felipe, helmut.haigermoser, kane.mx, kane.zhu, Silenio_Quarti, thomas, wb-rel |
| Version: | 3.6 | ||
| Target Milestone: | Juno M2 | ||
| Hardware: | PC | ||
| OS: | Linux-GTK | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 391795 | ||
|
Description
Martin Oberhuber
CQ:WIND00108178 Just ran into this again. On a remote host through VNC, the shell is swamped with errors so badly that I cannot even kill Eclipse to fix the DISPLAY. Wouldn't it be possible to make some GTK Sanity check before trying to open a Window? Do others GTK app perform this test for you ? (In reply to comment #0) > When launching Workbench on a Linux host, I'm getting a lot of confusing errors > when my DISPLAY variable is not correctly set. Wow, this is ugly! I'm getting the same messages on my RHWS5 machine, which is pretty vanilla (no custom gtk or anything). Also, there seems to be a regression in 3.6.1, a segmentation violation at the end (wrong icon size or something)(2), compared to a 3.6 launch(1). This being a regression makes me wonder if we can at least restore the ugly but non-segfaulting behavior of 3.6 in 3.6.2, or at least in 3.7? TIA, Ciao, hh [1] = launch 3.6 # /tmp/helmuth//test_crash/3.6/eclipse -vm /opt/work/installs/jdk-1.6.0_21/bin/java Xlib: connection to ":0.0" refused by server Xlib: No protocol specified <a LOT of gtk warnings like this last one:> (Eclipse:18236): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed <end (no crash)> [2] = launch 3.6.1 # /tmp/helmuth//test_crash/3.6.1/eclipse -vm /opt/work/installs/jdk-1.6.0_21/bin/java Xlib: connection to ":0.0" refused by server Xlib: No protocol specified <a LOT of gtk warnings like this last one:> (Eclipse:18255): Gtk-CRITICAL **: gtk_icon_theme_load_icon: assertion `GTK_IS_ICON_THEME (icon_theme)' failed Segmentation fault (In reply to comment #3) > Do others GTK app perform this test for you ? I remember seeing a gtk_init check that can be done to see if gtk is usable, Meng Xin, didn't we use that in our exe? TIA, Ciao, hh I did some debugging to see which code causes the gtk error messages. I think SWT did well job to check the gtk environment. SWT calls the API 'gtk_init_check' to check whether gtk library could work on that environment, then throws SWTError if the checking is failed, such as no gtk library installed or no display is configured correctly. The problem is caused by eclipse launcher, which never does those similar checkings. 1. if the eclipse is launched without option '-noSplash', the native eclipse launch would try to show the splash screen. So users would see many gtk error messages mentioned in above comments 2. if the eclipse is launched to run some GUI application, the SWT would error due to the gtk environment is not ready. Anyways the application meets any exception, the equinox launcher would exit with error data. The native launcher of equinox would try to open a dialog to tell users to check the log files. So it also causes many gtk errors or even segmentation fault(since 3.6.1) if the gtk window can't be initialized. The correct component of this defect should be Equinox - Launcher. Meng Xing - thanks for this investigation! Reassigning to Equinox / Launcher for comments. I'm marking this MAJOR since it's relatively common in a networked environment to log in to a remote machine and forget setting the DISPLAY. Getting bombarded with an avalanche of obscure errors, followed by a segfault, is a particularly unfortunate dealing with this common case and doesn't help finding or fixing the underlying problem. This, to me, meets the definition of "major loss of functionality" since it can take long for lots of people to understand what's causing the problem. *** Bug 168558 has been marked as a duplicate of this bug. *** Fixed. If gtk_init_check returns false we then proceed the same as if the gtk libraries were not present on the machine. No splash screen will be displayed and the SWT will complain or a headless application which does not need the display will continue happily. When attempting to display an error message, in this case the launcher will print it to stdout. Just checking ... is this something that could be backported to 3.7.2 ? It has repeatedly confused our users . Thanks, Martin |