Bug 231024 - segmentation fault while checking out from cvs
Summary: segmentation fault while checking out from cvs
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: CVS (show other bugs)
Version: 3.4   Edit
Hardware: PC Linux
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: platform-cvs-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-05-07 21:31 EDT by Alan Haggarty CLA
Modified: 2019-09-06 15:38 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alan Haggarty CLA 2008-05-07 21:31:50 EDT
Build ID: Version: 3.4.0
Build id: I20080502-0100

Steps To Reproduce:
I can consistently get the workbench to fault with the following conditions and steps.

IBM JRE 1.4.2 SR9 or 10
RHEL4WS
Linux leakbotl.torolab.ibm.com 2.6.9-67.0.7.ELsmp #1 SMP Wed Feb 27 04:48:20 EST 2008 i686 i686 i386 GNU/Linux
Running on the desktop which is GNOME 2.8.0
eclipse linux distrib - eclipse-SDK-3.4M7-linux-gtk.tar.gz

1. untar eclipse and launch
2. change to cvs perspective
3. check out tptp automated test framework:
:pserver:anonymous@dev.eclipse.org:/cvsroot/tptp
HEAD->test-results->platform->org.eclipse.tptp.testautomation
4. click run in background, switch to java perspective and wait (not 100% sure this step is needed)

In my env. this will always fault sometime during the check out.

To console:
[haggarty@leakbotl eclipse]$ JVMDG217: Dump Handler is Processing Signal 11 - Please Wait.
JVMDG303: JVM Requesting Java core file
Unrecoverable Stack Overflow: addr=  70f2d8, ee=8559294, er=bfedc6a8
JVMDG304: Java core file written to /tmp/eclipse/javacore.20080507.212219.1650.txt
JVMDG215: Dump Handler has Processed Exception Signal 11.
[haggarty@leakbotl eclipse]$ ./eclipse &
[2] 1698
[1]   Segmentation fault      ./eclipse
[haggarty@leakbotl eclipse]$



More information:
From the javacore:
0SECTION       XHPI subcomponent dump routine
NULL           ==============================
1HPTIME        Wed May 07 21:22:19 2008
1HPSIGRECV     SIGSEGV received in ?? at 0x4c6c380 in /home/haggarty/IBMJava2-142/jre/bin/libjitc.so. Processing terminated.
1HPFULLVERSION J2RE 1.4.2 IBM build cxia32142-20080122 (SR10)

...

This is a big file. If you need anything else from it let me know and I will provide it.
Comment 1 Alan Haggarty CLA 2008-05-08 09:25:34 EDT
I should add this problem did not happen on a SUSE machine with IBM 1.4.2 JRE not did it happen on the same machine with Sun 1.4.2_16 JRE.
Comment 2 Michael Valenta CLA 2008-05-08 09:31:46 EDT
Alan, my guess is that the problem you are seeing is due to a JIT error in the VM (i.e. libjitc.so appears in the trace and it happens "after a while"). To test this theory, you could run in debug mode by including the vm argument -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000.
Comment 3 Alan Haggarty CLA 2008-06-06 11:24:13 EDT
I cannot reproduce the problem after adding
-Xdebug and
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000
to the eclipse.ini file.

I still can reproduce it otherwise.
Comment 4 Alan Haggarty CLA 2008-06-06 11:26:09 EDT
Severity should be higher IMO even though only reproducible in one configuration for me since result is workbench crash .
Comment 5 Tomasz Zarna CLA 2008-06-20 09:28:58 EDT
Alan have you tried switching to IBM JRE 5.0. It seems that the problem only occurs to this specific configuration: RHEL4WS + IBM VM, is that right?
Comment 6 Alan Haggarty CLA 2008-06-20 10:02:22 EDT
Does not reproduce with IBM JRE 1.5 SR5 on the same host.

Actually after reproducing with I20080613-2000 workbench I could not even start the workbench again after the initial fault - right after selecting workspace it would fault again. Adding the 1.5 JRE to the top of my PATH fixed this.

I didn't try 1.5 originally because I was testing JVMPI profiling which is only supported with 1.4.2.
Comment 7 Eclipse Webmaster CLA 2019-09-06 15:38:10 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.