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.
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
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.
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.
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
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.
