Bug 72926 – eclipse-sdk-2.1.3-r5 +blackdown-jdk-1.4.1-r1 results in unexpected signal 10

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Ferris McCormick (RETIRED) 2004-11-30 08:03:43 UTC]

After upgrading eclipse from eclipse-sdk-2.1.3-r3 to -r5 and blackdown-jdk-1.4.1 to -r1,
eclipse-2 aborts with the long error trace shown at the URL portion of this bug report.
System is: 2.4.27-sparc-r1 #1 SMP Thu Sep 9 19:01:42 UTC 2004 sparc64 sun4u TI UltraSparc II  (BlackBird) GNU/Linux

All software current as of the date of this report.

Note that '-r3' + '1.4.1' did not exhibit this sort of problem.  Unfortunately, I can't tell
if it is the eclipse upgrade of the blackdown upgrade which triggers this.  I neglected to
backup the old versions before running this upgrade, and the old versions are gone.

[Comment 1 Thomas Matthijs (RETIRED) 2004-11-30 09:10:13 UTC]

its shoulb be eclipse, because that blackdown rev bump was to remove the installed plugins because of a security bug, all the rest was unchanged

[Comment 2 Ferris McCormick (RETIRED) 2004-11-30 15:37:36 UTC]

Just a note to indicate that eclipse-sdk-2.1.3-r3 and blackdown-jdk-1.4.1-r1 do indeed appear to
play together.  This test was on a different U60, however, so it is not conclusive, but it does
support Thomas's assertion.

[Comment 3 Ferris McCormick (RETIRED) 2004-12-01 15:31:31 UTC]

Well, an upgrade on a second U60 runs fine, and in theory, the only differences between the two systems are the kernel and xorg-x11.
The 2.4.27 kernel system fails, 2.6.6 succeeds.  The failing system is running
xorg-x11-6.8.0-r4 while the succeeding system runs -r3. (And -r4 is truly hardened and uses dlloader; -r3 is not hardened and uses xorg loader.)
Everything else of the failing system and succeeding system is built hardened.

I'll go back and rebuild on the failing system.  But unfortunately, the traceback
file is of no use to me at all.

[Comment 4 Ferris McCormick (RETIRED) 2004-12-02 11:13:17 UTC]

This problem is not consistently reproducible, as follows:

1. eclipse-2 run on U60 seems never to run, but except for the initial install,
   failures vary from run to run.  (The initial install always eventually gets
   the BUS error).
2. eclipse-2 run on U2 seems OK.
3. Running eclipse-2 on U60 from the U2 (a U60 xterm on U2) runs mostly but not
   always.  Again, failures seem to vary, but there are so few it's hard to tell. 
3a. Running eclipse-2 on U2 remote from U60 is OK.
4.  The U60-native failures fall into a pattern which says select one of these:
    a. Bus error (identical screen dumps);
    b. "Another exception has been detected while we were handling last error"
    c. Bus error in ld-linux.so
    d. Segfault somewhere (e.g., libc.so, libz.so, actually)
5.  U60-native RUNS FINE AS ROOT:

NOTES:
------
1. The systems are running identical (same package) xorg-x11-6.8.0-r4 (hardened)
2. U60 is 2x450MHz SMP; U2 is 2x400.
3. U60 graphics is Elite3d-m3; U2 is Creator3D,Series3.  Both use sunffb driver.
4. Xorg log does not show anything
5. This all strongly suggests that I have permissons set incorrectly on U60,
   causing the Xserver to abort native normal users.  But what it is will take
   some thought, since the U2 Xserver (identical to U60) lets U60 run.  And
   it's not X itself because I just reinstalled U60-xorg using the U2-xorg
   'emerge -b ...' package.

   A good candidate I suppose is memory resource related??
==========
I'm becoming convinced that this is not an eclipse problem, but I'm not quite ready to
take this back as a user error (although it is almost certainly an invalid error, I need to
think a little more about what the Xserver itself might be asking for, and why
U2 can run remote on U60, U60 remote on U2.....):
U60       --- *bad
U60(root) --- good
U60 on U2 --- good
U2 on U60 --- good

[Comment 5 Ferris McCormick (RETIRED) 2004-12-03 12:25:24 UTC]

OK, the solution to this was a reboot, so I guess eclipse is off the hook.  I suppose a simple logoff/logon sequence would have
worked, too.

This does leave two issues; one eclipse-related and one not.
1. eclipse's error reporting in this case was really not helpful (Signal 10 somewhere undeterminable).
   Since I don't know what triggered the fault, I don't know if eclipse could have
   done better.

2.  Apparently, some finite resource is preiodically allocated but never returned.
    So in this case, there was not enough of it left for (eclipse+X) to coexist
    on this system.  I suppose it's memory.
    But I'll have to wait for another 50 or 60 days continuous login session to
    look at it, so I can't complain too much.

I'm taking this back and closing it.