This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

java/4947: In certain circumstances, a CORBA based application built with GCJ 3.0.1 doesn't work as expected.

[Get raw message]

>Number:         4947
>Category:       java
>Synopsis:       In certain circumstances, a CORBA based application built with GCJ 3.0.1 doesn't work as expected.
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Nov 26 01:26:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Philippe Drauge
>Release:        GCJ 3.0.1
>Organization:
>Environment:
PC/Linux (RedHat 6.2)
>Description:
I built a CORBA based application using Orbacus for Java and I performed native compilation with GCJ 3.0.1 to improve performances.
In some circumstances my application doesn't work as expected. Ultimately, I built a very simple application to check and reproduce the problem: That simple application consists of a server and a client; The client invokes synchronously (two ways invocation via CORBA) two methodes of the server. The first one is supposed to raise an exception defined in the IDL interface of the server, the second on contains an out parameter.
I performed a set of test, in bytecode mode and native mode (compilation and link with GCJ) including the following configurations:
-Both client and server in bytecode mode,
-Both client and server in native mode,
-The client in bytecode mode and the server in native mode,
-The client in native mode and the server in bytecode mode.

It turned out that problems occured when the client is in native mode:
-When the client invokes the methode of the server that raises an exception, the exception doesn't reach the client application.
-When the client invokes the methode of the server that contains an out parameter, the invocation doesn't return.

In both cases the client hangs waiting for the return from the server.

In bytecode mode everything workes as expected (... but very slowly !!!).

To build the applications in native mode, I have "unjared" the OB.jar file (Orbacus class files), have compiled with GCJ all the class files of the jar file and the class files of my applications, and I linked all the resulting o files with the appropriate library to get the executables.

The OB.jar can be retrieved from the Orbacus web site (www.orbacus.com). The version I used is the 4.0.5.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]