Question

I am developing an Eclipse/Equinox based OSGI WebApplication (using embedded Jetty) and using headless PDE-Build for building the app. My build creates a zip file for Linux GTK and one for my local macosx.

This has worked well so far and I could just unzip the linux zip file on my Debian based server and run ./eclipse from the command line and the app would start up.

Yesterday I had a new build ready and deployed it, unzipped it and started ./eclipse and nothing happened. No output…nothing. It returned me the command line prompt immediately.

christoph@myserver:~/myapp$ ./eclipse 
christoph@myserver:~/myapp$

What I have tried afterwards was starting manually with the equinox launcher:

christoph@myserver:~/myapp$ java -jar plugins/org.eclipse.equinox.launcher_1.0.200.v20090520.jar

This looked much better and the application seemed to start as usual….but after about 10 seconds it stopped in the middle of startup and I was back at the command line prompt.

Does anybody have an idea what could be the reason or how I can debug whats going on with the eclipse startup file? I think I haven’t changed anything in the build scripts for weeks and the resulting zip file has the usual size what it was before. I also rebooted the server.

I have tried things like ./eclipse -noexit, ./eclipse -debug, ./eclipse -clean and ./eclipse -refresh , ./eclipse -vm /path/to/my/jdk/java but everything has the same effect. No output, nothing.

Thanks
Christoph

Answer 1

Update: This problem has been solved. Scroll to the bottom of this answer for the solution.

Yeah, I think I found it…by coincidence.
I am not yet sure what the root cause is, but I know which symptom causes the startup problems.

Basically I think it is related to race-conditions of my Build-process and the Delta-pack and the following jar file / folders:

Folder: org.eclipse.equinox.launcher.gtk.linux.x86_1.0.200.v20090520

vs.

Jar: org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519.jar

The spot which I stumbled upon were a few messages during the build which I saw a lot, but never really thought about:
E.g.

[java] [eclipse.generateFeature]
Bundle
org.eclipse.equinox.launcher.gtk.linux.x86:
[java] [eclipse.generateFeature] Another singleton version selected:
org.eclipse.equinox.launcher.gtk.linux.x86_1.0.200.v20090520

This sounds like the build processed picked something else…?!? Which seems odd to me.

In the case where it was working this jar file was extracted (so that it was a folder with the name org.eclipse.equinox.launcher.gtk.linux.x86_1.0.200.v20090520) and this folder contained a file called eclipse_1206.so.

In the case where it was not working there was also a folder with the name org.eclipse.equinox.launcher.gtk.linux.x86_1.0.200.v20090520 but the file eclipse_1206.so was NOT in this folder.

I also verified that on my local Ubuntu machine and which gave me some more output in the not working case than the Debian machine.

When it was not working under Ubuntu I got something like this:

$ ./eclipse

(.:26981): GLib-GObject-WARNING **:
invalid (NULL) pointer instance

(.:26981): GLib-GObject-CRITICAL **:
g_signal_connect_data: assertion
`G_TYPE_CHECK_INSTANCE (instance)’
failed

(.:26981): Gtk-CRITICAL **:
gtk_settings_get_for_screen: assertion
`GDK_IS_SCREEN (screen)’ failed

(.:26981): GLib-GObject-CRITICAL **:
g_object_get: assertion `G_IS_OBJECT
(object)’ failed

(.:26981): GLib-GObject-WARNING **:
value “TRUE” of type gboolean' is
invalid or out of range for property
visible’ of type `gboolean’

(.:26981): Gtk-CRITICAL **:
gtk_settings_get_for_screen: assertion
`GDK_IS_SCREEN (screen)’ failed

(.:26981): GLib-GObject-CRITICAL **:
g_object_get: assertion `G_IS_OBJECT
(object)’ failed

(.:26981): Gtk-WARNING **: Screen for
GtkWindow not set; you must always set
a screen for a GtkWindow before using
the window

(.:26981): Gdk-CRITICAL **:
gdk_pango_context_get_for_screen:
assertion `GDK_IS_SCREEN (screen)’
failed

(.:26981): Pango-CRITICAL **:
pango_context_set_font_description:
assertion `context != NULL’ failed

(.:26981): Pango-CRITICAL **:
pango_context_set_base_dir: assertion
`context != NULL’ failed

(.:26981): Pango-CRITICAL **:
pango_context_set_language: assertion
`context != NULL’ failed

(.:26981): Pango-CRITICAL **:
pango_layout_new: assertion `context
!= NULL’ failed

(.:26981): Pango-CRITICAL **:
pango_layout_set_text: assertion
`layout != NULL’ failed

(.:26981): Pango-CRITICAL **:
pango_layout_set_attributes: assertion
`layout != NULL’ failed

(.:26981): Pango-CRITICAL **:
pango_layout_set_alignment: assertion
`layout != NULL’ failed

(.:26981): Pango-CRITICAL **:
pango_layout_set_ellipsize: assertion
`PANGO_IS_LAYOUT (layout)’ failed

(.:26981): Pango-CRITICAL **:
pango_layout_set_single_paragraph_mode:
assertion `PANGO_IS_LAYOUT (layout)’
failed

(.:26981): Pango-CRITICAL **:
pango_layout_set_width: assertion
`layout != NULL’ failed

(.:26981): Pango-CRITICAL **:
pango_layout_get_extents: assertion
`layout != NULL’ failed

(.:26981): Gtk-CRITICAL **:
gtk_icon_theme_get_for_screen:
assertion `GDK_IS_SCREEN (screen)’
failed

(.:26981): Gtk-CRITICAL **:
gtk_settings_get_for_screen: assertion
`GDK_IS_SCREEN (screen)’ failed

(.:26981): Gtk-CRITICAL **:
gtk_icon_size_lookup_for_settings:
assertion `GTK_IS_SETTINGS (settings)’
failed

(.:26981): Gtk-WARNING **: Invalid
icon size 6

(.:26981): Gtk-CRITICAL **:
gtk_icon_theme_load_icon: assertion
`GTK_IS_ICON_THEME (icon_theme)’
failed Segmentation fault

On a hosted Debian machine (vserver.de) I got NO output as described in my opening question above.

Probably during the build process sometimes the former and sometimes the latter was used. I cannot explain why at the moment. I also notice that the folder is for the plain _x86 (32bit) architecture, while the jar is for the x86_64 (64bit) architecture. Not sure why the 64 is picked at all, because I didn’t specify x86_64 in my build.properties.

Also what I don’t understand is the fact that the resulting folder with the name org.eclipse.equinox.launcher.gtk.linux.x86_1.0.200.v20090520 contained the file eclipse_1206.so, even though this file is ONLY present in the org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519.jar (note the …x86_64…)

Conclusion
I think the root cause is, that I have some kind of inconsistent / broken / messed up targetplatform or delta-pack. Maybe I am also doing something wrong the way how I do the headless PDE build, but I could not tell so far because it seemed to work…sometimes…and sometimes not 🙂

I verified my statement above by exchanging the accordant folder with the one which contained the eclipse_1206.so file and suddenly it worked. Reproducible.
So, if you have similar startup problems under Linux, maybe check for the existence of the eclipse_1206.so in the equinox launcher folder / jar (e.g. org.eclipse.equinox.launcher.gtk.linux.x86_1.0.200.v20090520)

In the meantime I will investigate what the root cause was and how to setup the build properly and will write that down in a blog post.

Thanks to everybody trying to help out so far.

Christoph

Update Solution:
The solution was to download a fresh Eclipse Deltapack for the 3.5 version and replace all my ..launcher.. plugins in my target platform with the fresh ones. The problem was a corrupt launcher plugin which had the eclipse_1206.so file missing.

Update 2010/03/01: On another note,I found out that SVN by default ignores the file extension .so which was also a source of my problems.
My solution I described above was only working locally so far which was correct.
But today I wanted to check if the builds comming out of my build server are also correct finally and surprise..they were still broken. I instantly checked the launcher plugin folder and see..the eclipse_1206.so was missing again. Then I checked the SVN repository and really the file wasn’t there. It turnes out that SVN ignores those files by default which I now have described here: SVN ingnores .so files by default