From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6719 invoked by alias); 26 Nov 2001 09:26:00 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 6685 invoked by uid 71); 26 Nov 2001 09:26:00 -0000 Resent-Date: 26 Nov 2001 09:26:00 -0000 Resent-Message-ID: <20011126092600.6684.qmail@sourceware.cygnus.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-To: nobody@gcc.gnu.org Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, java-prs@gcc.gnu.org Resent-Reply-To: gcc-gnats@gcc.gnu.org, Philippe.Drauge@fr.thalesgroup.com Received:(qmail 6540 invoked by uid 61); 26 Nov 2001 09:24:11 -0000 Message-Id:<20011126092411.6539.qmail@sourceware.cygnus.com> Date: Tue, 20 Nov 2001 22:56:00 -0000 From: Philippe.Drauge@fr.thalesgroup.com Reply-To: Philippe.Drauge@fr.thalesgroup.com To: gcc-gnats@gcc.gnu.org X-Send-Pr-Version:gnatsweb-2.9.2 (1.1.1.1.2.21) Subject: java/4947: In certain circumstances, a CORBA based application built with GCJ 3.0.1 doesn't work as expected. X-SW-Source: 2001-11/txt/msg00621.txt.bz2 List-Id: >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: