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