Bug 238173

Summary: Uncaught exception attempting to edit configure.in
Product: [Fedora] Fedora Reporter: Davide Bolcioni <dblistsub-redzilla>
Component: eclipse-cdtAssignee: Jeff Johnston <jjohnstn>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6   
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-05-02 20:00:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Exception trace
none
Problematic configure.in from OpenExchange 0.8.2
none
Backwards configure.ac none

Description Davide Bolcioni 2007-04-27 17:45:48 UTC
Description of problem: When attempting to edit configure.in, the part cannot 
be created because of an uncaught exception.


Version-Release number of selected component (if applicable):
eclipse-cdt-3.1.2-2.fc6
eclipse-platform-3.2.2-2.fc6

How reproducible: Always.

Steps to Reproduce:
1. Reopen old project (OpenExchange, mixing Java and autotools)
2. Double click on configure.in
3. 
  
Actual results:
The part cannot be created (see attached log).

Expected results:
Editing the part

Additional info:

Comment 1 Davide Bolcioni 2007-04-27 17:45:48 UTC
Created attachment 153648 [details]
Exception trace

Comment 2 Jeff Johnston 2007-04-27 18:41:52 UTC
You are failing in the gcj Character class.  This should not be happening and
has nothing to do with CDT.  The CDT passes an int to the static isLetterOrDigit
method and the method has no defined exception that it throws.

What level of gcc do you currently have installed?  Can you provide a copy of
the configure.in which causes the error so we might possibly recreate a small
test-case for the gcj folks?

Please try the following to work-around the problem:

1. updating your gcc (which will update your gcj)
or if that doesn't work
2. try using a third-party jvm (use the -vm command when you start eclipse).


Comment 3 Davide Bolcioni 2007-04-28 09:13:36 UTC
Created attachment 153691 [details]
Problematic configure.in from OpenExchange 0.8.2

Comment 4 Davide Bolcioni 2007-04-28 09:26:48 UTC
Installed software

$ rpm -qa \*gcc\* \*java\* | sort -u
ant-javamail-1.6.5-2jpp.2
compat-gcc-34-3.4.6-4
compat-gcc-34-c++-3.4.6-4
compat-gcc-34-g77-3.4.6-4
compat-libgcc-296-2.96-138
gcc-4.1.1-51.fc6
gcc-c++-4.1.1-51.fc6
gcc-java-4.1.1-51.fc6
java-1.4.2-gcj-compat-1.4.2.0-40jpp.110
java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp.110
java-1.4.2-gcj-compat-javadoc-1.4.2.0-40jpp.110
java-1.5.0-sun-1.5.0.10-2jpp
java-1.5.0-sun-alsa-1.5.0.10-2jpp
java-1.5.0-sun-fonts-1.5.0.10-2jpp
javasvn-1.1.0-0.3.beta4.fc6
junit-javadoc-3.8.2-3jpp.1
libgcc-4.1.1-51.fc6
subversion-javahl-1.4.3-2.fc6

AFAIK, my gcc is at the latest official update.


Using the following

  eclipse -vm /usr/lib/jvm/jre-1.5.0-sun/bin/java

I get no exception and trivial editing of the above file works fine.

Comment 5 Davide Bolcioni 2007-04-28 09:32:56 UTC
owever, creating a new empty "Standard Make" project, converting it to 
autotools (it's still empty, mind you), creating a top-level configure.ac and 
attempting to edit it using the vm above results in a surprising occurrence.

The layout is

$ ls -R hello1
hello1:
build  configure.ac  src

hello1/build:

hello1/src:
hello.cpp  hello.h

I intended to write in the first line of configure.ac

  # A sample configure.ac

but what I saw is

  # ca.erguifnoc lepmas A

Maybe I should take that as proof that Leonardo da Vinci was an Autotools 
forerunner :-)

Comment 6 Davide Bolcioni 2007-04-28 09:34:55 UTC
Created attachment 153692 [details]
Backwards configure.ac

It's not a display problem, the text is composed backwards.

Comment 7 Jeff Johnston 2007-04-30 21:05:29 UTC
(In reply to comment #6)
> Created an attachment (id=153692) [edit]
> Backwards configure.ac
> 
> It's not a display problem, the text is composed backwards.

This is a totally separate problem.  A separate bug: 238493 has been opened and
closed as a fix has just been made.

Comment 8 Jeff Johnston 2007-05-02 20:00:38 UTC
Original problem has been reproduced on x86_64 with simple gcj test case and
bugzilla 238755 has been opened.

Closing this bug as a duplicate.

*** This bug has been marked as a duplicate of 238755 ***

Comment 9 Jeff Johnston 2007-05-10 20:53:32 UTC
I have applied a work-around to the sources which cast to (char) before calling
the Character method.  This avoids the problem.  It will be part a future build.