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

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

[neroden]

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

State-Changed-From-To: feedback->closed
State-Changed-By: neroden
State-Changed-When: Tue Oct 22 16:04:42 2002
State-Changed-Why:
    No feedback forthcoming.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=4947

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

[rodrigc]

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

State-Changed-From-To: open->feedback
State-Changed-By: rodrigc
State-Changed-When: Tue Feb 26 18:41:20 2002
State-Changed-Why:
    Can you reproduce this with GCJ 3.0.4, or a GCJ 3.1 snapshot?

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=4947

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

[Philippe.Drauge]

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