Segfault on simple HelloWorld

Segfault on simple HelloWorld

[James CE Johnson]

Forgive the newcomer...

I'm interested in using Java classes from my C++ app.  I just tripped
across gcj a few weeks ago & started messing with it.  The simple test
case I have below segfaults.

[jcej@node04 tmp]$ cat Makefile

INCLDIR  = -I
$(HOME)/ThirdParty/objdir/i686-pc-linux-gnu/libjava/include
INCLDIR += -I $(HOME)/ThirdParty/libgcj-2.95.1/libjava/include
INCLDIR += -I $(HOME)/ThirdParty/libgcj-2.95.1/libjava

run : Test
        LD_LIBRARY_PATH=/usr/local/lib ./Test

gdb : Test
        LD_LIBRARY_PATH=/usr/local/lib gdb ./Test

Test : main.o Test.o
        gcj -o Test main.o Test.o

main.o : main.cpp Test.h
        g++ $(INCLDIR) -c main.cpp

Test.class : Test.java
        javac -classpath . Test.java

Test.h : Test.class
        gcjh --classpath . Test

Test.o : Test.class
        gcj -c Test.class

clean realclean :
        rm -f Test.o main.o Test.h Test.class Test

[jcej@node04 tmp]$ cat main.cpp

#include "Test.h"

int main(int,char**)
{
        Test * test = new Test();

        test->HelloWorld(); // This is line 8

        delete test;

        return 0;
}

[jcej@node04 tmp]$ cat Test.java

public class Test
{
    public int HelloWorld()
    {
        System.out.println("Hello World");
        return 0; // This is line 7
    }
}

[jcej@node04 tmp]$ make gdb
javac -classpath . Test.java
gcjh --classpath . Test
g++ -I /home2/jcej/ThirdParty/objdir/i686-pc-linux-gnu/libjava/include
-I /home2
/jcej/ThirdParty/libgcj-2.95.1/libjava/include -I
/home2/jcej/ThirdParty/libgcj-
2.95.1/libjava -c main.cpp
gcj -c Test.class
gcj -o Test main.o Test.o
LD_LIBRARY_PATH=/usr/local/lib gdb ./Test
GNU gdb 4.17
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i586-pc-linux-gnu"...
(gdb) run
Starting program: /home2/jcej/tmp/./Test
Hello World

Program received signal SIGSEGV, Segmentation fault.
0x400b3844 in java::lang::Thread::interrupted ()
    at
/home2/jcej/ThirdParty/libgcj-2.95.1/libjava/java/lang/Thread.java:276
276       }
Current language:  auto; currently java
(gdb) bt
#0  0x400b3844 in java::lang::Thread::interrupted ()
    at
/home2/jcej/ThirdParty/libgcj-2.95.1/libjava/java/lang/Thread.java:276
#1  0x400ebfae in java::io::FileDescriptor::write ()
    at java/io/natFileDescriptor.cc:232
#2  0x4009b1c0 in java::io::FileOutputStream::write ()
    at
/home2/jcej/ThirdParty/libgcj-2.95.1/libjava/java/io/FileOutputStream.jav

a:34
#3  0x40094043 in java::io::BufferedOutputStream::flush ()
    at
/home2/jcej/ThirdParty/libgcj-2.95.1/libjava/java/io/BufferedOutputStream

.java:70
#4  0x400a0ddd in java::io::PrintStream::flush ()
    at
/home2/jcej/ThirdParty/libgcj-2.95.1/libjava/java/io/PrintStream.java:90

#5  0x400a0efc in java::io::PrintStream::print ()
    at
/home2/jcej/ThirdParty/libgcj-2.95.1/libjava/java/io/PrintStream.java:90

#6  0x400a19b5 in java::io::PrintStream::println ()
    at
/home2/jcej/ThirdParty/libgcj-2.95.1/libjava/java/io/PrintStream.java:90

#7  0x804ad9e in Test.HelloWorld ()
#8  0x804ad14 in main ()
#9  0x401dfa12 in __libc_start_main ()
(gdb) The program is running.  Exit anyway? (y or n) y

CNI invocation [was Re: Segfault on simple HelloWorld]

[Bryce McKinlay]

James CE Johnson wrote:

> Forgive the newcomer...
>
> I'm interested in using Java classes from my C++ app.  I just tripped
> across gcj a few weeks ago & started messing with it.  The simple test
> case I have below segfaults.

Hi James,

CNI so far has no "invocation interface" to allow Java code to be called
from a program with a C/C++ "main" method. The libgcj runtime assumes that
some initialization code has been run at startup (such as setting up the
java.lang.Thread environment, but there are possibly a few other things).
This initialization code only gets run from a java binary generated by gcj,
before the java programs "main" gets run.

libgcj currently creates a new thread in which to run the java "main"
method, while the initial thread simply waits and does nothing for the
lifetime of the process. It should be possible to initialize the thread
environment such that the current thread becomes the primary java thread. It
seems to me that doing this will also solve much of the invocation problem.

The interface might look something like this:

JvInitRuntime()  // Called once from C++ programs before calling into Java
code. Do any libgcj initialization stuff, and convert the current thread to
be the "main" java thread.

Of course, interactions with existing C++ code that already uses pthreads
will need to be considered. Perhaps it could simply detect if JvInitRuntime
has already been run from another thread, and if so register the current
thread as an ordinary java thread rather than going through the "main"
initialization stuff.

It shouldn't be too difficult to add this feature (patches are welcome!).
For now, you could try using JNI (supported in current libgcj snapshots), or
create a simple java "main" class to call your C++ main method, and link
your application using "gcj --main=xxx". In fact, "public static native void
main(String args[])" should probibly work ;-)

regards

  [ bryce ]

Re: CNI invocation [was Re: Segfault on simple HelloWorld]

[James CE Johnson]

Bryce McKinlay wrote:

> James CE Johnson wrote:
>
> > Forgive the newcomer...
> >
> > I'm interested in using Java classes from my C++ app.  I just tripped
> > across gcj a few weeks ago & started messing with it.  The simple test
> > case I have below segfaults.
>
> Hi James,
>
> CNI so far has no "invocation interface" to allow Java code to be called
> from a program with a C/C++ "main" method. The libgcj runtime assumes that
> some initialization code has been run at startup (such as setting up the
> java.lang.Thread environment, but there are possibly a few other things).
> This initialization code only gets run from a java binary generated by gcj,
> before the java programs "main" gets run.

Ah.  Well.  I guess that makes sense.

Not to be deterred I tried your suggestion:  A simple Java wrapper for a
traditional "main".  Strange I suppose, but it seems to behave.

[jcej@node04 tmp]$ cat Main.java

public class Main
{
   public native static void run();

   public static void main(String args[])
   {
      run();
   }
}

[jcej@node04 tmp]$ cat Run.cpp

#include "Main.h"
#include "Test.h"

#include <cni.h>

void Main::run(void)
{
   Test * test = new Test();

   test->HelloWorld();

   // deleting Java objects is
   // apparently a bad idea...
   // delete test;

   return;
}

Re: Segfault on simple HelloWorld

[Tom Tromey]

James> Test.o : Test.class
James>         gcj -c Test.class

FYI we recommend compiling from .java to .o, because you can get
better optimization this way.

Tom

Re: CNI invocation [was Re: Segfault on simple HelloWorld]

[Tom Tromey]

Bryce> For now, you could try using JNI (supported in current libgcj
Bryce> snapshots), or create a simple java "main" class to call your
Bryce> C++ main method, and link your application using "gcj
Bryce> --main=xxx". In fact, "public static native void main(String
Bryce> args[])" should probibly work ;-)

If you're going to make a native Foo.main() you could just make it use
CNI.

Our JNI includes an invocation interface, but it has never been tested
and, I would venture, almost certainly has bugs.  My JNI testing has
been (temporarily) derailed by other work.

Tom

internal error - SP mismatch

[James CE Johnson]

I guess I'm just one of those trouble-maker newbies...

Flushed with success from last night's testing (thanks Bryce & Tom), I decided
to try mixing some exising .class files with my simple testcase.  Well,
libgcj-2.95.1 doesn't include gij so I tried to build the latest snapshot & got
the error above.

My gcc is a recently built 2.95.2.

My configure parameters to libgcj are:
     --enable-threads=posix --enable-java-gc=boehm --enable-interpreter

This is on a Linux 2.2.14 box that more or less has everything up to date.

java/math/BigInteger.java: In class `java.math.BigInteger':
java/math/BigInteger.java: In method `isNegative()':
java/math/BigInteger.java:282: internal error - SP mismatch
Premature end of .class file
/home2/jcej/ThirdParty/libgcj-objdir/i686-pc-linux-gnu/libjava/java/math/BigInteger.class.

Premature end of .class file
/home2/jcej/ThirdParty/libgcj-objdir/i686-pc-linux-gnu/libjava/java/math/BigInteger.class.

Premature end of .class file
/home2/jcej/ThirdParty/libgcj-objdir/i686-pc-linux-gnu/libjava/java/math/BigInteger.class.

Premature end of .class file
/home2/jcej/ThirdParty/libgcj-objdir/i686-pc-linux-gnu/libjava/java/math/BigInteger.class.

Premature end of .class file
/home2/jcej/ThirdParty/libgcj-objdir/i686-pc-linux-gnu/libjava/java/math/BigInteger.class.

Premature end of .class file
/home2/jcej/ThirdParty/libgcj-objdir/i686-pc-linux-gnu/libjava/java/math/BigInteger.class.

Premature end of .class file
/home2/jcej/ThirdParty/libgcj-objdir/i686-pc-linux-gnu/libjava/java/math/BigInteger.class.

make[2]: *** [libgcj.zip] Error 1
make[2]: Leaving directory
`/home2/jcej/ThirdParty/libgcj-objdir/i686-pc-linux-gnu/libjava'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/home2/jcej/ThirdParty/libgcj-objdir/i686-pc-linux-gnu/libjava'
make: *** [all-target-libjava] Error 2

Re: internal error - SP mismatch

[Jeff Sturm]

James CE Johnson wrote:
> 
> I guess I'm just one of those trouble-maker newbies...
> 
> Flushed with success from last night's testing (thanks Bryce & Tom), I decided
> to try mixing some exising .class files with my simple testcase.  Well,
> libgcj-2.95.1 doesn't include gij so I tried to build the latest snapshot & got
> the error above.
> 
> My gcc is a recently built 2.95.2.
[...]

I don't think you can build libgcj snapshots with gcc-2.95.2 any
longer.  The only options are:

- stick with libgcj 2.95.1
- get a gcc snapshot (and cross your fingers... recent snapshots
  are notoriously unstable)
- wait for next release (no timetable yet, but a release coordinator has
  been assigned for gcc 3.0, a good start at least)

-- 
Jeff Sturm
jsturm@sigma6.com

Re: internal error - SP mismatch

[Tom Tromey]

Jeff> - get a gcc snapshot (and cross your fingers... recent snapshots
Jeff>   are notoriously unstable)

Before you try this, note that gcc hasn't been able to build libgcj
for about 2 weeks.  Right now the development gcc can't even bootstrap
on x86.  So don't waste any time downloading gcc -- you'll just be
frustrated (like me :-).  If you can find a slightly older snapshot,
that might work.  Of course, then you'll be missing some of Alex's
improvements to the Java front end.  Sigh.

Tom

Re: internal error - SP mismatch

[Matt Welsh]

Tom Tromey <tromey@cygnus.com> writes:
> Jeff> - get a gcc snapshot (and cross your fingers... recent snapshots
> Jeff>   are notoriously unstable)
> 
> Before you try this, note that gcc hasn't been able to build libgcj
> for about 2 weeks.  Right now the development gcc can't even bootstrap
> on x86.  So don't waste any time downloading gcc -- you'll just be
> frustrated (like me :-).  If you can find a slightly older snapshot,
> that might work.  Of course, then you'll be missing some of Alex's
> improvements to the Java front end.  Sigh.

Or, you can try using gcc-2.95.2 with the latest libgcj *and* the patches
from Bryce at:
	http://waitaki.otago.ac.nz/~bryce/gcj/

This is what I'm experimenting with at the moment but I am running into some
bugs which appear to be race conditions in the threads implementation (although
it might be my application code, I'm not sure yet).

Now, does anyone else think that we should do something about making these
things more explicit on the web page? This is *extremely* frustrating.

Matt

Re: internal error - SP mismatch

[James CE Johnson]

(Sorry for the dual-copies Jeff.  I forgot to reply to the list instead of direct.)

  Jeff Sturm wrote:

  > James CE Johnson wrote:
  > >
  > > I guess I'm just one of those trouble-maker newbies...
  > >
  > > Flushed with success from last night's testing (thanks Bryce & Tom), I decided

  > > to try mixing some exising .class files with my simple testcase.  Well,
  > > libgcj-2.95.1 doesn't include gij so I tried to build the latest snapshot &
got
  > > the error above.
  > >
  > > My gcc is a recently built 2.95.2.
  > [...]
  >
  > I don't think you can build libgcj snapshots with gcc-2.95.2 any
  > longer.  The only options are:
  >
  > - stick with libgcj 2.95.1

  <whine>But it doesn't include gij</whine>
  What are the odds me of dropping the snapshot gij.cc into 2.95.1 & succeeding?

  > - get a gcc snapshot (and cross your fingers... recent snapshots
  >   are notoriously unstable)

  Can't do that.  The other developers would thwap me soundly!

  > - wait for next release (no timetable yet, but a release coordinator has
  >   been assigned for gcc 3.0, a good start at least)

  That sounds like the best plan.

  I grossed-up BigInteger.java & got it to compile but there are a *lot* of things
  complaining about java-array.h missing.

  Ah well...  I'll drop into a holding pattern for a while & check back for 3.0.

  Just got Tom's note.  Waiting for stability is sounding better & better...

  Thanks ya'll,
  J

  > --
  > Jeff Sturm
  > jsturm@sigma6.com

Re: internal error - SP mismatch

[Tom Tromey]

Matt> Or, you can try using gcc-2.95.2 with the latest libgcj *and*
Matt> the patches from Bryce at:

I thought this had problems with the new exception-handling stuff that
libgcj assumes is in the C++ front end :-(

Matt> Now, does anyone else think that we should do something about
Matt> making these things more explicit on the web page? This is
Matt> *extremely* frustrating.

Sure.  Could you write a patch against the web page?  I'm
unfortunately very busy these days & probably won't have time to do it
soon.

T

Re: internal error - SP mismatch

[Tom Tromey]

James>   What are the odds me of dropping the snapshot gij.cc into
James>   2.95.1 & succeeding?

About zero.

James>   I grossed-up BigInteger.java & got it to compile but there
James>   are a *lot* of things complaining about java-array.h missing.

This is because gcjh also changed -- libgcj 2.95.1 assumes the
2.95.[12] gcjh.

James>   Ah well...  I'll drop into a holding pattern for a while &
James>   check back for 3.0.

There might be a 2.95.3 that includes the new gcj.
We don't know yet :-(
I'll post a note here if/when I find out anything definite.

Tom

Re: internal error - SP mismatch

[James CE Johnson]

Matt Welsh wrote:

> Tom Tromey <tromey@cygnus.com> writes:
> > Jeff> - get a gcc snapshot (and cross your fingers... recent snapshots
> > Jeff>   are notoriously unstable)
> >
> > Before you try this, note that gcc hasn't been able to build libgcj
> > for about 2 weeks.  Right now the development gcc can't even bootstrap
> > on x86.  So don't waste any time downloading gcc -- you'll just be
> > frustrated (like me :-).  If you can find a slightly older snapshot,
> > that might work.  Of course, then you'll be missing some of Alex's
> > improvements to the Java front end.  Sigh.
>
> Or, you can try using gcc-2.95.2 with the latest libgcj

By "latest libgcj" do you mean the stable 2.95.1 version or the one at the head of
the CVS repository?  Assuming you mean the former, I'm gonna go try that now.

> *and* the patches
> from Bryce at:
>         http://waitaki.otago.ac.nz/~bryce/gcj/
>
> This is what I'm experimenting with at the moment but I am running into some
> bugs which appear to be race conditions in the threads implementation (although
> it might be my application code, I'm not sure yet).
>
> Now, does anyone else think that we should do something about making these
> things more explicit on the web page? This is *extremely* frustrating.

As a newcomer... I'd vote for a note that says which snapshots work with which
gcc.

>
>
> Matt

Re: internal error - SP mismatch

[Tom Tromey]

>> Or, you can try using gcc-2.95.2 with the latest libgcj

James> By "latest libgcj" do you mean the stable 2.95.1 version or the
James> one at the head of the CVS repository?  Assuming you mean the
James> former, I'm gonna go try that now.

The rule is: gcj and libgcj must match.
gcc 2.95.1 and gcc 2.95.2 match libgcj 2.95.1.
the cvs gcc matches the cvs libgcj
  (except the cvs gcc is broken)
gcc 2.95.2 + Bryce's "back porting" patch matches the cvs libgcj
  (except there are bugs)

James> As a newcomer... I'd vote for a note that says which snapshots
James> work with which gcc.

I agree this would be nice.  In practice no one seems to have time to
do this consistently.

Tom

Re: internal error - SP mismatch

[James CE Johnson]

Tom Tromey wrote:

> >> Or, you can try using gcc-2.95.2 with the latest libgcj
>
> James> By "latest libgcj" do you mean the stable 2.95.1 version or the
> James> one at the head of the CVS repository?  Assuming you mean the
> James> former, I'm gonna go try that now.
>
> The rule is: gcj and libgcj must match.
> gcc 2.95.1 and gcc 2.95.2 match libgcj 2.95.1.
> the cvs gcc matches the cvs libgcj
>   (except the cvs gcc is broken)
> gcc 2.95.2 + Bryce's "back porting" patch matches the cvs libgcj
>   (except there are bugs)

Ok. Gotcha.

- Use the stable 2.95.2 gcc version.
- Grab libgcj from CVS (using the tag `pre-cni-catch-change' says Bryce's
web page)
- Apply the patches to gcc & libgcj
- Cross fingers
- make
- test

So far I'm about to start crossing my fingers.  It'll probably be a while
before I know anything one way or another.

> James> As a newcomer... I'd vote for a note that says which snapshots
> James> work with which gcc.
>
> I agree this would be nice.  In practice no one seems to have time to
> do this consistently.

Oh, believe me, I know the feeling.  I fight those same battles with
myself and my co-developers on stuff that our boss is expecting us to
deliver!

> Tom

Re: internal error - SP mismatch

[Matt Welsh]

Tom Tromey <tromey@cygnus.com> writes:
> Matt> Or, you can try using gcc-2.95.2 with the latest libgcj *and*
> Matt> the patches from Bryce at:
> 
> I thought this had problems with the new exception-handling stuff that
> libgcj assumes is in the C++ front end :-(

Ah, you're right. I'm not using the latest libgcj -- I'm using the one
just before the CNI catch changes were put in.

> Sure.  Could you write a patch against the web page?  

I can do that, but what I think we really need is a "current status" page
which says "The current stable version is X, but the following newer versions
have been used as well..."

I'll write up a skeleton of this webpage and send it to you.

Matt

Re: internal error - SP mismatch

[ks]

> 
> > Tom Tromey <tromey@cygnus.com> writes:
> > > Jeff> - get a gcc snapshot (and cross your fingers... recent snapshots
> > > Jeff>   are notoriously unstable)
> > >
> > > Before you try this, note that gcc hasn't been able to build libgcj
> > > for about 2 weeks.  Right now the development gcc can't even bootstrap
> > > on x86.  So don't waste any time downloading gcc -- you'll just be
> > > frustrated (like me :-).  If you can find a slightly older snapshot,
> > > that might work.  Of course, then you'll be missing some of Alex's
> > > improvements to the Java front end.  Sigh.
> >
> > Or, you can try using gcc-2.95.2 with the latest libgcj
> 
> By "latest libgcj" do you mean the stable 2.95.1 version or the one at the head of
> the CVS repository?  Assuming you mean the former, I'm gonna go try that now.
> 
> > *and* the patches
> > from Bryce at:
> >         http://waitaki.otago.ac.nz/~bryce/gcj/
> >

If you are willing to drop back a couple of weeks, the libgcj from Mar 14
was working fine for me together with the Bryce patches over gcc-2.95.2.

It would be really handy if one of the libgcj developers who has a working
build of gcc from the live repository could put add a tag to gcc indicating
what is working.

Cheers,
-kls

Re: internal error - SP mismatch

[Matt Welsh]

James CE Johnson <jcej@tragus.org> writes:
> 
> By "latest libgcj" do you mean the stable 2.95.1 version or the one at the he
> ad of
> the CVS repository?  Assuming you mean the former, I'm gonna go try that now.

I'm sorry, I was wrong.

I am using gcc-2.95.2 with Bryce's patches, as well as the latest 
version of libgcj *before* some changes were made to support throw/catch
in CNI. This version is from
	02 Mar 2000 00:00:00
so you can get it with something like
	cvs co -D "March 2, 2000 00:00:00" libgcj
Note that Bryce has a patch that you need to apply on top of this
(libgcj-interface-dispatch-2.patch).

As I said, however, I am running into problems with threads with this version,
which I am trying to fix now.

Note that some, but not all, of the files in this directory were labelled
with the tag "pre-cni-catch-change". You could try checking out this version
from CVS, but it's confusing because not all of the files in the libgcj
directory were tagged with this, and the default behavior for libgcj is to
check out any files *not* tagged with the newest version. Unfortunately 
the resulting tree won't compile. Best to check it out by date as shown above.

Matt

> As a newcomer... I'd vote for a note that says which snapshots work with whic
> h
> gcc.

Absolutely. I'll write a "Status" page and get it added to the website.
If people have reports on what versions of gcj/libgcj they are using 
successfully on different platforms, I will add them to that page...

Matt

Re: internal error - SP mismatch

[Tom Tromey]

Matt> Note that some, but not all, of the files in this directory were
Matt> labelled with the tag "pre-cni-catch-change". You could try
Matt> checking out this version from CVS, but it's confusing because
Matt> not all of the files in the libgcj directory were tagged with
Matt> this, and the default behavior for libgcj is to check out any
Matt> files *not* tagged with the newest version. Unfortunately the
Matt> resulting tree won't compile. Best to check it out by date as
Matt> shown above.

What was missed?
We can fix this.

T

Re: internal error - SP mismatch

[Matt Welsh]

Tom Tromey <tromey@cygnus.com> writes:
> Matt> Note that some, but not all, of the files in this directory were
> Matt> labelled with the tag "pre-cni-catch-change". You could try
> Matt> checking out this version from CVS, but it's confusing because
> Matt> not all of the files in the libgcj directory were tagged with
> Matt> this, and the default behavior for libgcj is to check out any
> Matt> files *not* tagged with the newest version. Unfortunately the
> Matt> resulting tree won't compile. Best to check it out by date as
> Matt> shown above.
> 
> What was missed?

Everything outside of the libjava directory, as far as I can tell.

libgcj port status (was: Re: internal error - SP mismatch)

[Jeff Sturm]

Matt Welsh wrote:
> Absolutely. I'll write a "Status" page and get it added to the website.
> If people have reports on what versions of gcj/libgcj they are using
> successfully on different platforms, I will add them to that page...

That's a great idea... it'd be nice to have a summary not just of what
ports are working, but what features work (or don't work) and what ports
are in progress, and who's working on them.

Personally I've been testing with Linux/Alpha, Linux/x86 and Win32. 
Status is roughly:

Platform    Version  Status       GC      threads       interpreter
-------------------------------------------------------------------
Linux/x86   2.95.1   working      boehm   posix         no
Linux/x86   snapshot builds       boehm   posix         yes
Linux/Alpha 2.95.1   working      boehm   posix         no
Win32       snapshot builds       no[1]   win32         maybe[2]

[1] - Boehm is ported to Win32, I have successfully built it for libgcj
but gctest does not yet succeed

[2] - I have partial support for Win32 in libffi but have not yet tested
the interpreter

What do you think of this format?

-- 
Jeff Sturm
jsturm@sigma6.com

Re: libgcj port status (was: Re: internal error - SP mismatch)

[Matt Welsh]

I put together a web page which looks something like this. Wait until
Tom puts it online (it'll be the new 'Download' page) and send me 
updates to it.

gij with gcc 2.95.2 (was: Re: internal error - SP mismatch)

[James CE Johnson]

Matt Welsh wrote:

> James CE Johnson <jcej@tragus.org> writes:
> >
> > By "latest libgcj" do you mean the stable 2.95.1 version or the one at the he
> > ad of
> > the CVS repository?  Assuming you mean the former, I'm gonna go try that now.
>
> I'm sorry, I was wrong.
>
> I am using gcc-2.95.2 with Bryce's patches, as well as the latest
> version of libgcj *before* some changes were made to support throw/catch
> in CNI. This version is from
>         02 Mar 2000 00:00:00
> so you can get it with something like
>         cvs co -D "March 2, 2000 00:00:00" libgcj
> Note that Bryce has a patch that you need to apply on top of this
> (libgcj-interface-dispatch-2.patch).

Ok, I'm getting a little closer now.

I've patched gcc 2.95.2 and the 3/2/2000 version of libgjc.  I even have a shinny
new gij binary which was, after all, the point of the exercise.

But now, I'm embarrased to say, I can't seem to figure out how to use the darned
thing:

[jcej@node04 T3]$ gcj -shared -c -o HelloWorld.so HelloWorld.java
[jcej@node04 T3]$ gij HelloWorld
java.lang.ClassNotFoundException: HelloWorld
   at 0x400e4e4b: java::lang::Throwable::Throwable(java::lang::String *)
(/usr/local/lib/libgcj.so.1)
   at 0x400d8984: java::lang::Exception::Exception(java::lang::String *)
(/usr/local/lib/libgcj.so.1)
   at 0x400d7cf4:
java::lang::ClassNotFoundException::ClassNotFoundException(java::lang::String *)
(/usr/local/lib/libgcj.so.1)
   at 0x400fcc44: java::net::URLClassLoader::findClass(java::lang::String *)
(/usr/local/lib/libgcj.so.1)
   at 0x400d71d6: java::lang::ClassLoader::loadClass(java::lang::String *, bool)
(/usr/local/lib/libgcj.so.1)
   at 0x401331a4: _Jv_FindClass(_Jv_Utf8Const *, java::lang::ClassLoader *)
(/usr/local/lib/libgcj.so.1)
   at 0x40130382: java::lang::Class::forName(java::lang::String *)
(/usr/local/lib/libgcj.so.1)
   at 0x40133f8a: java::lang::FirstThread::run(void) (/usr/local/lib/libgcj.so.1)
   at 0x400e20c2: java::lang::Thread::run_(void) (/usr/local/lib/libgcj.so.1)
   at 0x40139aca: java::lang::Thread::run__(java::lang::Object *)
(/usr/local/lib/libgcj.so.1)
   at 0x4014a6c2: _Jv_ThreadSetPriority(_Jv_Thread_t *, int)
(/usr/local/lib/libgcj.so.1)
   at 0x401eaf16: GC_start_routine (/usr/local/lib/libgcjgc.so.1)
   at 0x40203ccf: pthread_detach (/lib/libpthread.so.0)
   at 0x402d71ba: __clone (/lib/libc.so.6)
addr2line: /proc/10380/exe: No such file or directory

[jcej@node04 T3]$ pwd
/home2/jcej/projects/personal/gcj/T3

[jcej@node04 T3]$ echo $CLASSPATH
/home2/jcej/projects/personal/gcj/T3

[jcej@node04 T3]$ echo $LD_LIBRARY_PATH
/home2/jcej/projects/personal/gcj/T3:/usr/local/lib


If I javac HelloWorld.java then things work.  The complete example is at
http://www.lads.com/~jcej/gcj/T3/

But if I extend the example to do a CNI call then I find myself back in the same
boat.  I put the entire test case at http://www.lads.com/~jcej/gcj/T4/ in case
anyone wants to point out the error of my ways...  The file 'results' is the
output of compiling & trying to execute.

Threads [was Re: internal error - SP mismatch]

[Bryce McKinlay]

Matt Welsh wrote:

> This is what I'm experimenting with at the moment but I am running into some
> bugs which appear to be race conditions in the threads implementation (although
> it might be my application code, I'm not sure yet).

Matt, can I ask you to try my new posix-threads patch at:

 http://sourceware.cygnus.com/ml/java-patches/2000-q1/msg00248.html

There are definatly some nasty threads bugs in the current libgcj, which may or
may not manifest themselves on the various different glibc versions. The new code
should work much better.

regards

  [ bryce ]

Re: gij with gcc 2.95.2 (was: Re: internal error - SP mismatch)

[Tom Tromey]

>>>>> "James" == James CE Johnson <jcej@tragus.org> writes:

James> But now, I'm embarrased to say, I can't seem to figure out how
James> to use the darned thing:

James> [jcej@node04 T3]$ gcj -shared -c -o HelloWorld.so HelloWorld.java
James> [jcej@node04 T3]$ gij HelloWorld

You can't use both `-shared' and `-c', but gcc doesn't tell you that
(oops).  Omit the -c and this will work.

Or, compile all the way to an executable:

    gcj --main=HelloWorld -o HelloWorld HelloWorld.java

Or, compile to bytecode and interpret:

    gcj -C HelloWorld.java
    gij HelloWorld

Tom

Re: gij with gcc 2.95.2 (was: Re: internal error - SP mismatch)

[Matt Welsh]

> But now, I'm embarrased to say, I can't seem to figure out how to use the dar
> ned
> thing:
> 
> [jcej@node04 T3]$ gcj -shared -c -o HelloWorld.so HelloWorld.java

This is a problem with gcc and gcj. Use of "-c" actually causes gcj
to build a STATIC object file, even though you used "-shared". Try 
removing the "-c" and see if it works.

Arguably this is a bug, but it appears in much older versions of gcc
as well, so I don't know what the right fix is.

Also, I think you need to have the directory where 'HelloWorld.so' 
is located on your LD_LIBRARY_PATH. This is silly, of course, and we had
some discussion earlier on what the right mechanism should be.

I just tried this myself and it segfaults for some reason. 
Your example above will work if you just do:
	gcj -C Hello.java
	gij Hello

But, in this case gij will actually be interpreting the bytecodes for
Hello.class rather than loading the compiled Hello.so shared object. 
gij *does* support loading shared objects, but I don't know why it's
crashing here.

Also be sure you compiled libgcj with the --enable-interpreter=yes option
to "configure".

Matt 

Re: gij with gcc 2.95.2 (was: Re: internal error - SP mismatch)

[Matt Welsh]

Matt Welsh <mdw@CS.Berkeley.EDU> writes:
> 
> I just tried this myself and it segfaults for some reason. 

Running gdb on 'gij Hello' I get the following stack trace when it
segfaults. 

I am leaving for a trip out of town in a couple of hours and won't be 
back until Wednesday ... maybe it'll be fixed by the time I get back :-)

Matt

#0  _dl_lookup_versioned_symbol (undef_name=0x4024c2bc "_dl_close", 
    ref=0xbf7ff7b8, symbol_scope=0x402049bc, 
    reference_name=0x402047a8 "/lib/libc.so.6", version=0x40204d80, 
    reloc_type=7) at do-lookup.h:82
#1  0x40009cfa in fixup (l=0x402047b8, reloc_offset=42) at dl-runtime.c:75
#2  0x40009e70 in _dl_runtime_resolve () at dl-runtime.c:170
#3  0x401e6730 in dlopen_doit (a=0xbf7ff8f8) at dlopenold.c:43
#4  0x4000a12b in _dl_catch_error (errstring=0x80912ec, 
    operate=0x401e6708 <dlopen_doit>, args=0xbf7ff8f8) at dl-error.c:141
#5  0x401e6608 in _dlerror_run (operate=0x401e6708 <dlopen_doit>, 
    args=0xbf7ff8f8) at dlerror.c:122
#6  0x401e66f5 in __dlopen_nocheck (file=0xbf7ffaac "Hello", mode=257)
    at dlopenold.c:58
#7  0x401f0e6d in GC_dlopen (path=0xbf7ffaac "Hello", mode=257)
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/boehm-gc/dyn_load.c:266
#8  0x4014d5e3 in sys_dl_open (handle=0x80912b0, filename=0xbf7ffaac "Hello")
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/libltdl/ltdl.c:270
#9  0x4014dbd5 in tryall_dlopen (handle=0xbf7ffa50, 
    filename=0xbf7ffaac "Hello")
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/libltdl/ltdl.c:947
#10 0x4014ed3b in lt_dlopen (filename=0xbf7ffaac "Hello")
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/libltdl/ltdl.c:1373
#11 0x4014ef0c in lt_dlopenext (filename=0xbf7ffaac "Hello")
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/libltdl/ltdl.c:1427
#12 0x40137a18 in java::lang::Runtime::loadLibraryInternal (this=0x8068f20, 
    lib=0x8063ea0)
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/java/lang/natRuntime.cc:170
#13 0x40134fb8 in gnu::gcj::runtime::VMClassLoader::findSystemClass (
    this=0x8067e58, name=0x8063ea0)
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/java/lang/natClassLoader.cc:212
#14 0x400d94b9 in java.lang.ClassLoader.loadClass (this=0x8067e58, 
    name=0x8063ea0, link=false)
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/java/lang/ClassLoader.java:107
#15 0x40135546 in _Jv_FindClass (name=0x805feb0, loader=0x0)
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/java/lang/natClassLoader.cc:472
#16 0x40132702 in java::lang::Class::forName (className=0x8063ec0)
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/java/lang/natClass.cc:98
#17 0x4013632a in java::lang::FirstThread::run (this=0x8064ea0)
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/java/lang/natFirstThread.cc:37
#18 0x400e43f2 in java.lang.Thread.run_ (this=0x8064ea0)
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/java/lang/Thread.java:134
#19 0x4013be6a in java::lang::Thread::run__ (obj=0x8064ea0)
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/java/lang/natThread.cc:291
#20 0x4014ca52 in really_start (x=0x805fed0)
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/posix-threads.cc:336
#21 0x401f2d16 in GC_start_routine (arg=0x8084fe0)
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/boehm-gc/linux_threads.c:553
#22 0x40209ce9 in pthread_start_thread (arg=0xbf7ffe7c) at manager.c:204

Re: Threads [was Re: internal error - SP mismatch]

[Matt Welsh]

Bryce McKinlay <bryce@albatross.co.nz> writes:
> Matt, can I ask you to try my new posix-threads patch at:
> 
>  http://sourceware.cygnus.com/ml/java-patches/2000-q1/msg00248.html

You are my hero :-) I will try them out when I get back later this week.
 
> There are definatly some nasty threads bugs in the current libgcj, 

That would really help explain what I'm seeing now. Thanks!!

Matt

Re: gij with gcc 2.95.2 (was: Re: internal error - SP mismatch)

[James CE Johnson]

Ok...

This works:
    [jcej@node04 T3]$ rm -f *.so *.class
    [jcej@node04 T3]$ gcj -C HelloWorld.java
    [jcej@node04 T3]$ gij HelloWorld
    Hello World

As does this:
    [jcej@node04 T3]$ rm -f *.so *.class
    [jcej@node04 T3]$ gcj -shared -o HelloWorld.so HelloWorld.java
    [jcej@node04 T3]$ gij HelloWorld
    Hello World

Both of those with this trivial HelloWorld.java:
    public class HelloWorld
    {
       public static void main(String args[])
       {
          System.err.println("Hello World");
       }
    }

Now I want to simulate using an object in some random .class file.  So I create:
class Foo
{
        public int Bar()
        {
                System.err.println("Foo::Bar");
                return 0;
        }
}

And change main():
public class HelloWorld
{
   public static void main(String args[])
   {
      System.err.println("Hello World");
      Foo foo = new Foo();
      foo.Bar();
   }
}

Compile everything to .class and we have success:

[jcej@node04 T3]$ rm -f *.so *.class
[jcej@node04 T3]$ gcj -C HelloWorld.java
[jcej@node04 T3]$ gcj -C Foo.java
[jcej@node04 T3]$ gij HelloWorld
Hello World
Foo::Bar

Try mixing native binary & .class and we have failure:

[jcej@node04 T3]$ rm -f *.so *.class
[jcej@node04 T3]$ gcj -C Foo.java
[jcej@node04 T3]$ gcj -shared -o HelloWorld.so HelloWorld.java
[jcej@node04 T3]$ gij HelloWorld
java.lang.ClassNotFoundException: HelloWorld
   at 0x400e4e4b: java::lang::Throwable::Throwable(java::lang::String *)
(/usr/local/lib/libgcj.so.1)
   at 0x400d8984: java::lang::Exception::Exception(java::lang::String *)
(/usr/local/lib/libgcj.so.1)
   at 0x400d7cf4:
java::lang::ClassNotFoundException::ClassNotFoundException(java::lang::String *)
(/usr/local/lib/libgcj.so.1)
   at 0x400fcc44: java::net::URLClassLoader::findClass(java::lang::String *)
(/usr/local/lib/libgcj.so.1)
   at 0x400d71d6: java::lang::ClassLoader::loadClass(java::lang::String *, bool)
(/usr/local/lib/libgcj.so.1)
   at 0x401331a4: _Jv_FindClass(_Jv_Utf8Const *, java::lang::ClassLoader *)
(/usr/local/lib/libgcj.so.1)
   at 0x40130382: java::lang::Class::forName(java::lang::String *)
(/usr/local/lib/libgcj.so.1)
   at 0x40133f8a: java::lang::FirstThread::run(void) (/usr/local/lib/libgcj.so.1)
   at 0x400e20c2: java::lang::Thread::run_(void) (/usr/local/lib/libgcj.so.1)
   at 0x40139aca: java::lang::Thread::run__(java::lang::Object *)
(/usr/local/lib/libgcj.so.1)
   at 0x4014a6c2: _Jv_ThreadSetPriority(_Jv_Thread_t *, int)
(/usr/local/lib/libgcj.so.1)
   at 0x401eaf16: GC_start_routine (/usr/local/lib/libgcjgc.so.1)
   at 0x40203ccf: pthread_detach (/lib/libpthread.so.0)
   at 0x402d71ba: __clone (/lib/libc.so.6)

[jcej@node04 T3]$ pwd
/home2/jcej/projects/personal/gcj/T3

[jcej@node04 T3]$ echo $CLASSPATH
/home2/jcej/projects/personal/gcj/T3

[jcej@node04 T3]$ echo $LD_LIBRARY_PATH
/home2/jcej/projects/personal/gcj/T3:/usr/local/lib


So... What did I do wrong this time?

Re: gij with gcc 2.95.2 (was: Re: internal error - SP mismatch)

[Anthony Green]

Matt wrote:
> Also be sure you compiled libgcj with the --enable-interpreter=yes option
> to "configure".

This is the default now for IA-32 Linux.

AG

-- 
Anthony Green                                                        Red Hat
                                                       Sunnyvale, California

Re: internal error - SP mismatch

[Tom Tromey]

James>   What are the odds me of dropping the snapshot gij.cc into
James>   2.95.1 & succeeding?

About zero.

James>   I grossed-up BigInteger.java & got it to compile but there
James>   are a *lot* of things complaining about java-array.h missing.

This is because gcjh also changed -- libgcj 2.95.1 assumes the
2.95.[12] gcjh.

James>   Ah well...  I'll drop into a holding pattern for a while &
James>   check back for 3.0.

There might be a 2.95.3 that includes the new gcj.
We don't know yet :-(
I'll post a note here if/when I find out anything definite.

Tom

internal error - SP mismatch

[James CE Johnson]

I guess I'm just one of those trouble-maker newbies...

Flushed with success from last night's testing (thanks Bryce & Tom), I decided
to try mixing some exising .class files with my simple testcase.  Well,
libgcj-2.95.1 doesn't include gij so I tried to build the latest snapshot & got
the error above.

My gcc is a recently built 2.95.2.

My configure parameters to libgcj are:
     --enable-threads=posix --enable-java-gc=boehm --enable-interpreter

This is on a Linux 2.2.14 box that more or less has everything up to date.

java/math/BigInteger.java: In class `java.math.BigInteger':
java/math/BigInteger.java: In method `isNegative()':
java/math/BigInteger.java:282: internal error - SP mismatch
Premature end of .class file
/home2/jcej/ThirdParty/libgcj-objdir/i686-pc-linux-gnu/libjava/java/math/BigInteger.class.

Premature end of .class file
/home2/jcej/ThirdParty/libgcj-objdir/i686-pc-linux-gnu/libjava/java/math/BigInteger.class.

Premature end of .class file
/home2/jcej/ThirdParty/libgcj-objdir/i686-pc-linux-gnu/libjava/java/math/BigInteger.class.

Premature end of .class file
/home2/jcej/ThirdParty/libgcj-objdir/i686-pc-linux-gnu/libjava/java/math/BigInteger.class.

Premature end of .class file
/home2/jcej/ThirdParty/libgcj-objdir/i686-pc-linux-gnu/libjava/java/math/BigInteger.class.

Premature end of .class file
/home2/jcej/ThirdParty/libgcj-objdir/i686-pc-linux-gnu/libjava/java/math/BigInteger.class.

Premature end of .class file
/home2/jcej/ThirdParty/libgcj-objdir/i686-pc-linux-gnu/libjava/java/math/BigInteger.class.

make[2]: *** [libgcj.zip] Error 1
make[2]: Leaving directory
`/home2/jcej/ThirdParty/libgcj-objdir/i686-pc-linux-gnu/libjava'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/home2/jcej/ThirdParty/libgcj-objdir/i686-pc-linux-gnu/libjava'
make: *** [all-target-libjava] Error 2

Re: internal error - SP mismatch

[James CE Johnson]

Tom Tromey wrote:

> >> Or, you can try using gcc-2.95.2 with the latest libgcj
>
> James> By "latest libgcj" do you mean the stable 2.95.1 version or the
> James> one at the head of the CVS repository?  Assuming you mean the
> James> former, I'm gonna go try that now.
>
> The rule is: gcj and libgcj must match.
> gcc 2.95.1 and gcc 2.95.2 match libgcj 2.95.1.
> the cvs gcc matches the cvs libgcj
>   (except the cvs gcc is broken)
> gcc 2.95.2 + Bryce's "back porting" patch matches the cvs libgcj
>   (except there are bugs)

Ok. Gotcha.

- Use the stable 2.95.2 gcc version.
- Grab libgcj from CVS (using the tag `pre-cni-catch-change' says Bryce's
web page)
- Apply the patches to gcc & libgcj
- Cross fingers
- make
- test

So far I'm about to start crossing my fingers.  It'll probably be a while
before I know anything one way or another.

> James> As a newcomer... I'd vote for a note that says which snapshots
> James> work with which gcc.
>
> I agree this would be nice.  In practice no one seems to have time to
> do this consistently.

Oh, believe me, I know the feeling.  I fight those same battles with
myself and my co-developers on stuff that our boss is expecting us to
deliver!

> Tom

Re: internal error - SP mismatch

[Tom Tromey]

>> Or, you can try using gcc-2.95.2 with the latest libgcj

James> By "latest libgcj" do you mean the stable 2.95.1 version or the
James> one at the head of the CVS repository?  Assuming you mean the
James> former, I'm gonna go try that now.

The rule is: gcj and libgcj must match.
gcc 2.95.1 and gcc 2.95.2 match libgcj 2.95.1.
the cvs gcc matches the cvs libgcj
  (except the cvs gcc is broken)
gcc 2.95.2 + Bryce's "back porting" patch matches the cvs libgcj
  (except there are bugs)

James> As a newcomer... I'd vote for a note that says which snapshots
James> work with which gcc.

I agree this would be nice.  In practice no one seems to have time to
do this consistently.

Tom

Threads [was Re: internal error - SP mismatch]

[Bryce McKinlay]

Matt Welsh wrote:

> This is what I'm experimenting with at the moment but I am running into some
> bugs which appear to be race conditions in the threads implementation (although
> it might be my application code, I'm not sure yet).

Matt, can I ask you to try my new posix-threads patch at:

 http://sourceware.cygnus.com/ml/java-patches/2000-q1/msg00248.html

There are definatly some nasty threads bugs in the current libgcj, which may or
may not manifest themselves on the various different glibc versions. The new code
should work much better.

regards

  [ bryce ]

Re: gij with gcc 2.95.2 (was: Re: internal error - SP mismatch)

[Matt Welsh]

Matt Welsh <mdw@CS.Berkeley.EDU> writes:
> 
> I just tried this myself and it segfaults for some reason. 

Running gdb on 'gij Hello' I get the following stack trace when it
segfaults. 

I am leaving for a trip out of town in a couple of hours and won't be 
back until Wednesday ... maybe it'll be fixed by the time I get back :-)

Matt

#0  _dl_lookup_versioned_symbol (undef_name=0x4024c2bc "_dl_close", 
    ref=0xbf7ff7b8, symbol_scope=0x402049bc, 
    reference_name=0x402047a8 "/lib/libc.so.6", version=0x40204d80, 
    reloc_type=7) at do-lookup.h:82
#1  0x40009cfa in fixup (l=0x402047b8, reloc_offset=42) at dl-runtime.c:75
#2  0x40009e70 in _dl_runtime_resolve () at dl-runtime.c:170
#3  0x401e6730 in dlopen_doit (a=0xbf7ff8f8) at dlopenold.c:43
#4  0x4000a12b in _dl_catch_error (errstring=0x80912ec, 
    operate=0x401e6708 <dlopen_doit>, args=0xbf7ff8f8) at dl-error.c:141
#5  0x401e6608 in _dlerror_run (operate=0x401e6708 <dlopen_doit>, 
    args=0xbf7ff8f8) at dlerror.c:122
#6  0x401e66f5 in __dlopen_nocheck (file=0xbf7ffaac "Hello", mode=257)
    at dlopenold.c:58
#7  0x401f0e6d in GC_dlopen (path=0xbf7ffaac "Hello", mode=257)
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/boehm-gc/dyn_load.c:266
#8  0x4014d5e3 in sys_dl_open (handle=0x80912b0, filename=0xbf7ffaac "Hello")
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/libltdl/ltdl.c:270
#9  0x4014dbd5 in tryall_dlopen (handle=0xbf7ffa50, 
    filename=0xbf7ffaac "Hello")
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/libltdl/ltdl.c:947
#10 0x4014ed3b in lt_dlopen (filename=0xbf7ffaac "Hello")
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/libltdl/ltdl.c:1373
#11 0x4014ef0c in lt_dlopenext (filename=0xbf7ffaac "Hello")
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/libltdl/ltdl.c:1427
#12 0x40137a18 in java::lang::Runtime::loadLibraryInternal (this=0x8068f20, 
    lib=0x8063ea0)
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/java/lang/natRuntime.cc:170
#13 0x40134fb8 in gnu::gcj::runtime::VMClassLoader::findSystemClass (
    this=0x8067e58, name=0x8063ea0)
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/java/lang/natClassLoader.cc:212
#14 0x400d94b9 in java.lang.ClassLoader.loadClass (this=0x8067e58, 
    name=0x8063ea0, link=false)
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/java/lang/ClassLoader.java:107
#15 0x40135546 in _Jv_FindClass (name=0x805feb0, loader=0x0)
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/java/lang/natClassLoader.cc:472
#16 0x40132702 in java::lang::Class::forName (className=0x8063ec0)
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/java/lang/natClass.cc:98
#17 0x4013632a in java::lang::FirstThread::run (this=0x8064ea0)
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/java/lang/natFirstThread.cc:37
#18 0x400e43f2 in java.lang.Thread.run_ (this=0x8064ea0)
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/java/lang/Thread.java:134
#19 0x4013be6a in java::lang::Thread::run__ (obj=0x8064ea0)
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/java/lang/natThread.cc:291
#20 0x4014ca52 in really_start (x=0x805fed0)
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/libjava/posix-threads.cc:336
#21 0x401f2d16 in GC_start_routine (arg=0x8084fe0)
    at /home/cs/mdw/disks/mm33/egcs-jaguar/src/libgcj-cvs-20000302/boehm-gc/linux_threads.c:553
#22 0x40209ce9 in pthread_start_thread (arg=0xbf7ffe7c) at manager.c:204

Re: internal error - SP mismatch

[James CE Johnson]

Matt Welsh wrote:

> Tom Tromey <tromey@cygnus.com> writes:
> > Jeff> - get a gcc snapshot (and cross your fingers... recent snapshots
> > Jeff>   are notoriously unstable)
> >
> > Before you try this, note that gcc hasn't been able to build libgcj
> > for about 2 weeks.  Right now the development gcc can't even bootstrap
> > on x86.  So don't waste any time downloading gcc -- you'll just be
> > frustrated (like me :-).  If you can find a slightly older snapshot,
> > that might work.  Of course, then you'll be missing some of Alex's
> > improvements to the Java front end.  Sigh.
>
> Or, you can try using gcc-2.95.2 with the latest libgcj

By "latest libgcj" do you mean the stable 2.95.1 version or the one at the head of
the CVS repository?  Assuming you mean the former, I'm gonna go try that now.

> *and* the patches
> from Bryce at:
>         http://waitaki.otago.ac.nz/~bryce/gcj/
>
> This is what I'm experimenting with at the moment but I am running into some
> bugs which appear to be race conditions in the threads implementation (although
> it might be my application code, I'm not sure yet).
>
> Now, does anyone else think that we should do something about making these
> things more explicit on the web page? This is *extremely* frustrating.

As a newcomer... I'd vote for a note that says which snapshots work with which
gcc.

>
>
> Matt

Re: gij with gcc 2.95.2 (was: Re: internal error - SP mismatch)

[Matt Welsh]

> But now, I'm embarrased to say, I can't seem to figure out how to use the dar
> ned
> thing:
> 
> [jcej@node04 T3]$ gcj -shared -c -o HelloWorld.so HelloWorld.java

This is a problem with gcc and gcj. Use of "-c" actually causes gcj
to build a STATIC object file, even though you used "-shared". Try 
removing the "-c" and see if it works.

Arguably this is a bug, but it appears in much older versions of gcc
as well, so I don't know what the right fix is.

Also, I think you need to have the directory where 'HelloWorld.so' 
is located on your LD_LIBRARY_PATH. This is silly, of course, and we had
some discussion earlier on what the right mechanism should be.

I just tried this myself and it segfaults for some reason. 
Your example above will work if you just do:
	gcj -C Hello.java
	gij Hello

But, in this case gij will actually be interpreting the bytecodes for
Hello.class rather than loading the compiled Hello.so shared object. 
gij *does* support loading shared objects, but I don't know why it's
crashing here.

Also be sure you compiled libgcj with the --enable-interpreter=yes option
to "configure".

Matt 

Re: gij with gcc 2.95.2 (was: Re: internal error - SP mismatch)

[Anthony Green]

Matt wrote:
> Also be sure you compiled libgcj with the --enable-interpreter=yes option
> to "configure".

This is the default now for IA-32 Linux.

AG

-- 
Anthony Green                                                        Red Hat
                                                       Sunnyvale, California

Re: internal error - SP mismatch

[Matt Welsh]

James CE Johnson <jcej@tragus.org> writes:
> 
> By "latest libgcj" do you mean the stable 2.95.1 version or the one at the he
> ad of
> the CVS repository?  Assuming you mean the former, I'm gonna go try that now.

I'm sorry, I was wrong.

I am using gcc-2.95.2 with Bryce's patches, as well as the latest 
version of libgcj *before* some changes were made to support throw/catch
in CNI. This version is from
	02 Mar 2000 00:00:00
so you can get it with something like
	cvs co -D "March 2, 2000 00:00:00" libgcj
Note that Bryce has a patch that you need to apply on top of this
(libgcj-interface-dispatch-2.patch).

As I said, however, I am running into problems with threads with this version,
which I am trying to fix now.

Note that some, but not all, of the files in this directory were labelled
with the tag "pre-cni-catch-change". You could try checking out this version
from CVS, but it's confusing because not all of the files in the libgcj
directory were tagged with this, and the default behavior for libgcj is to
check out any files *not* tagged with the newest version. Unfortunately 
the resulting tree won't compile. Best to check it out by date as shown above.

Matt

> As a newcomer... I'd vote for a note that says which snapshots work with whic
> h
> gcc.

Absolutely. I'll write a "Status" page and get it added to the website.
If people have reports on what versions of gcj/libgcj they are using 
successfully on different platforms, I will add them to that page...

Matt

Re: Segfault on simple HelloWorld

[Tom Tromey]

James> Test.o : Test.class
James>         gcj -c Test.class

FYI we recommend compiling from .java to .o, because you can get
better optimization this way.

Tom

Re: libgcj port status (was: Re: internal error - SP mismatch)

[Matt Welsh]

I put together a web page which looks something like this. Wait until
Tom puts it online (it'll be the new 'Download' page) and send me 
updates to it.

Re: internal error - SP mismatch

[Jeff Sturm]

James CE Johnson wrote:
> 
> I guess I'm just one of those trouble-maker newbies...
> 
> Flushed with success from last night's testing (thanks Bryce & Tom), I decided
> to try mixing some exising .class files with my simple testcase.  Well,
> libgcj-2.95.1 doesn't include gij so I tried to build the latest snapshot & got
> the error above.
> 
> My gcc is a recently built 2.95.2.
[...]

I don't think you can build libgcj snapshots with gcc-2.95.2 any
longer.  The only options are:

- stick with libgcj 2.95.1
- get a gcc snapshot (and cross your fingers... recent snapshots
  are notoriously unstable)
- wait for next release (no timetable yet, but a release coordinator has
  been assigned for gcc 3.0, a good start at least)

-- 
Jeff Sturm
jsturm@sigma6.com

Re: internal error - SP mismatch

[Matt Welsh]

Tom Tromey <tromey@cygnus.com> writes:
> Jeff> - get a gcc snapshot (and cross your fingers... recent snapshots
> Jeff>   are notoriously unstable)
> 
> Before you try this, note that gcc hasn't been able to build libgcj
> for about 2 weeks.  Right now the development gcc can't even bootstrap
> on x86.  So don't waste any time downloading gcc -- you'll just be
> frustrated (like me :-).  If you can find a slightly older snapshot,
> that might work.  Of course, then you'll be missing some of Alex's
> improvements to the Java front end.  Sigh.

Or, you can try using gcc-2.95.2 with the latest libgcj *and* the patches
from Bryce at:
	http://waitaki.otago.ac.nz/~bryce/gcj/

This is what I'm experimenting with at the moment but I am running into some
bugs which appear to be race conditions in the threads implementation (although
it might be my application code, I'm not sure yet).

Now, does anyone else think that we should do something about making these
things more explicit on the web page? This is *extremely* frustrating.

Matt

Re: internal error - SP mismatch

[James CE Johnson]

(Sorry for the dual-copies Jeff.  I forgot to reply to the list instead of direct.)

  Jeff Sturm wrote:

  > James CE Johnson wrote:
  > >
  > > I guess I'm just one of those trouble-maker newbies...
  > >
  > > Flushed with success from last night's testing (thanks Bryce & Tom), I decided

  > > to try mixing some exising .class files with my simple testcase.  Well,
  > > libgcj-2.95.1 doesn't include gij so I tried to build the latest snapshot &
got
  > > the error above.
  > >
  > > My gcc is a recently built 2.95.2.
  > [...]
  >
  > I don't think you can build libgcj snapshots with gcc-2.95.2 any
  > longer.  The only options are:
  >
  > - stick with libgcj 2.95.1

  <whine>But it doesn't include gij</whine>
  What are the odds me of dropping the snapshot gij.cc into 2.95.1 & succeeding?

  > - get a gcc snapshot (and cross your fingers... recent snapshots
  >   are notoriously unstable)

  Can't do that.  The other developers would thwap me soundly!

  > - wait for next release (no timetable yet, but a release coordinator has
  >   been assigned for gcc 3.0, a good start at least)

  That sounds like the best plan.

  I grossed-up BigInteger.java & got it to compile but there are a *lot* of things
  complaining about java-array.h missing.

  Ah well...  I'll drop into a holding pattern for a while & check back for 3.0.

  Just got Tom's note.  Waiting for stability is sounding better & better...

  Thanks ya'll,
  J

  > --
  > Jeff Sturm
  > jsturm@sigma6.com

Re: gij with gcc 2.95.2 (was: Re: internal error - SP mismatch)

[Tom Tromey]

>>>>> "James" == James CE Johnson <jcej@tragus.org> writes:

James> But now, I'm embarrased to say, I can't seem to figure out how
James> to use the darned thing:

James> [jcej@node04 T3]$ gcj -shared -c -o HelloWorld.so HelloWorld.java
James> [jcej@node04 T3]$ gij HelloWorld

You can't use both `-shared' and `-c', but gcc doesn't tell you that
(oops).  Omit the -c and this will work.

Or, compile all the way to an executable:

    gcj --main=HelloWorld -o HelloWorld HelloWorld.java

Or, compile to bytecode and interpret:

    gcj -C HelloWorld.java
    gij HelloWorld

Tom

Re: internal error - SP mismatch

[Tom Tromey]

Matt> Or, you can try using gcc-2.95.2 with the latest libgcj *and*
Matt> the patches from Bryce at:

I thought this had problems with the new exception-handling stuff that
libgcj assumes is in the C++ front end :-(

Matt> Now, does anyone else think that we should do something about
Matt> making these things more explicit on the web page? This is
Matt> *extremely* frustrating.

Sure.  Could you write a patch against the web page?  I'm
unfortunately very busy these days & probably won't have time to do it
soon.

T

Re: CNI invocation [was Re: Segfault on simple HelloWorld]

[James CE Johnson]

Bryce McKinlay wrote:

> James CE Johnson wrote:
>
> > Forgive the newcomer...
> >
> > I'm interested in using Java classes from my C++ app.  I just tripped
> > across gcj a few weeks ago & started messing with it.  The simple test
> > case I have below segfaults.
>
> Hi James,
>
> CNI so far has no "invocation interface" to allow Java code to be called
> from a program with a C/C++ "main" method. The libgcj runtime assumes that
> some initialization code has been run at startup (such as setting up the
> java.lang.Thread environment, but there are possibly a few other things).
> This initialization code only gets run from a java binary generated by gcj,
> before the java programs "main" gets run.

Ah.  Well.  I guess that makes sense.

Not to be deterred I tried your suggestion:  A simple Java wrapper for a
traditional "main".  Strange I suppose, but it seems to behave.

[jcej@node04 tmp]$ cat Main.java

public class Main
{
   public native static void run();

   public static void main(String args[])
   {
      run();
   }
}

[jcej@node04 tmp]$ cat Run.cpp

#include "Main.h"
#include "Test.h"

#include <cni.h>

void Main::run(void)
{
   Test * test = new Test();

   test->HelloWorld();

   // deleting Java objects is
   // apparently a bad idea...
   // delete test;

   return;
}

Re: internal error - SP mismatch

[Matt Welsh]

Tom Tromey <tromey@cygnus.com> writes:
> Matt> Note that some, but not all, of the files in this directory were
> Matt> labelled with the tag "pre-cni-catch-change". You could try
> Matt> checking out this version from CVS, but it's confusing because
> Matt> not all of the files in the libgcj directory were tagged with
> Matt> this, and the default behavior for libgcj is to check out any
> Matt> files *not* tagged with the newest version. Unfortunately the
> Matt> resulting tree won't compile. Best to check it out by date as
> Matt> shown above.
> 
> What was missed?

Everything outside of the libjava directory, as far as I can tell.

CNI invocation [was Re: Segfault on simple HelloWorld]

[Bryce McKinlay]

James CE Johnson wrote:

> Forgive the newcomer...
>
> I'm interested in using Java classes from my C++ app.  I just tripped
> across gcj a few weeks ago & started messing with it.  The simple test
> case I have below segfaults.

Hi James,

CNI so far has no "invocation interface" to allow Java code to be called
from a program with a C/C++ "main" method. The libgcj runtime assumes that
some initialization code has been run at startup (such as setting up the
java.lang.Thread environment, but there are possibly a few other things).
This initialization code only gets run from a java binary generated by gcj,
before the java programs "main" gets run.

libgcj currently creates a new thread in which to run the java "main"
method, while the initial thread simply waits and does nothing for the
lifetime of the process. It should be possible to initialize the thread
environment such that the current thread becomes the primary java thread. It
seems to me that doing this will also solve much of the invocation problem.

The interface might look something like this:

JvInitRuntime()  // Called once from C++ programs before calling into Java
code. Do any libgcj initialization stuff, and convert the current thread to
be the "main" java thread.

Of course, interactions with existing C++ code that already uses pthreads
will need to be considered. Perhaps it could simply detect if JvInitRuntime
has already been run from another thread, and if so register the current
thread as an ordinary java thread rather than going through the "main"
initialization stuff.

It shouldn't be too difficult to add this feature (patches are welcome!).
For now, you could try using JNI (supported in current libgcj snapshots), or
create a simple java "main" class to call your C++ main method, and link
your application using "gcj --main=xxx". In fact, "public static native void
main(String args[])" should probibly work ;-)

regards

  [ bryce ]

Re: internal error - SP mismatch

[ks]

> 
> > Tom Tromey <tromey@cygnus.com> writes:
> > > Jeff> - get a gcc snapshot (and cross your fingers... recent snapshots
> > > Jeff>   are notoriously unstable)
> > >
> > > Before you try this, note that gcc hasn't been able to build libgcj
> > > for about 2 weeks.  Right now the development gcc can't even bootstrap
> > > on x86.  So don't waste any time downloading gcc -- you'll just be
> > > frustrated (like me :-).  If you can find a slightly older snapshot,
> > > that might work.  Of course, then you'll be missing some of Alex's
> > > improvements to the Java front end.  Sigh.
> >
> > Or, you can try using gcc-2.95.2 with the latest libgcj
> 
> By "latest libgcj" do you mean the stable 2.95.1 version or the one at the head of
> the CVS repository?  Assuming you mean the former, I'm gonna go try that now.
> 
> > *and* the patches
> > from Bryce at:
> >         http://waitaki.otago.ac.nz/~bryce/gcj/
> >

If you are willing to drop back a couple of weeks, the libgcj from Mar 14
was working fine for me together with the Bryce patches over gcc-2.95.2.

It would be really handy if one of the libgcj developers who has a working
build of gcc from the live repository could put add a tag to gcc indicating
what is working.

Cheers,
-kls

Re: internal error - SP mismatch

[Tom Tromey]

Matt> Note that some, but not all, of the files in this directory were
Matt> labelled with the tag "pre-cni-catch-change". You could try
Matt> checking out this version from CVS, but it's confusing because
Matt> not all of the files in the libgcj directory were tagged with
Matt> this, and the default behavior for libgcj is to check out any
Matt> files *not* tagged with the newest version. Unfortunately the
Matt> resulting tree won't compile. Best to check it out by date as
Matt> shown above.

What was missed?
We can fix this.

T

libgcj port status (was: Re: internal error - SP mismatch)

[Jeff Sturm]

Matt Welsh wrote:
> Absolutely. I'll write a "Status" page and get it added to the website.
> If people have reports on what versions of gcj/libgcj they are using
> successfully on different platforms, I will add them to that page...

That's a great idea... it'd be nice to have a summary not just of what
ports are working, but what features work (or don't work) and what ports
are in progress, and who's working on them.

Personally I've been testing with Linux/Alpha, Linux/x86 and Win32. 
Status is roughly:

Platform    Version  Status       GC      threads       interpreter
-------------------------------------------------------------------
Linux/x86   2.95.1   working      boehm   posix         no
Linux/x86   snapshot builds       boehm   posix         yes
Linux/Alpha 2.95.1   working      boehm   posix         no
Win32       snapshot builds       no[1]   win32         maybe[2]

[1] - Boehm is ported to Win32, I have successfully built it for libgcj
but gctest does not yet succeed

[2] - I have partial support for Win32 in libffi but have not yet tested
the interpreter

What do you think of this format?

-- 
Jeff Sturm
jsturm@sigma6.com

gij with gcc 2.95.2 (was: Re: internal error - SP mismatch)

[James CE Johnson]

Matt Welsh wrote:

> James CE Johnson <jcej@tragus.org> writes:
> >
> > By "latest libgcj" do you mean the stable 2.95.1 version or the one at the he
> > ad of
> > the CVS repository?  Assuming you mean the former, I'm gonna go try that now.
>
> I'm sorry, I was wrong.
>
> I am using gcc-2.95.2 with Bryce's patches, as well as the latest
> version of libgcj *before* some changes were made to support throw/catch
> in CNI. This version is from
>         02 Mar 2000 00:00:00
> so you can get it with something like
>         cvs co -D "March 2, 2000 00:00:00" libgcj
> Note that Bryce has a patch that you need to apply on top of this
> (libgcj-interface-dispatch-2.patch).

Ok, I'm getting a little closer now.

I've patched gcc 2.95.2 and the 3/2/2000 version of libgjc.  I even have a shinny
new gij binary which was, after all, the point of the exercise.

But now, I'm embarrased to say, I can't seem to figure out how to use the darned
thing:

[jcej@node04 T3]$ gcj -shared -c -o HelloWorld.so HelloWorld.java
[jcej@node04 T3]$ gij HelloWorld
java.lang.ClassNotFoundException: HelloWorld
   at 0x400e4e4b: java::lang::Throwable::Throwable(java::lang::String *)
(/usr/local/lib/libgcj.so.1)
   at 0x400d8984: java::lang::Exception::Exception(java::lang::String *)
(/usr/local/lib/libgcj.so.1)
   at 0x400d7cf4:
java::lang::ClassNotFoundException::ClassNotFoundException(java::lang::String *)
(/usr/local/lib/libgcj.so.1)
   at 0x400fcc44: java::net::URLClassLoader::findClass(java::lang::String *)
(/usr/local/lib/libgcj.so.1)
   at 0x400d71d6: java::lang::ClassLoader::loadClass(java::lang::String *, bool)
(/usr/local/lib/libgcj.so.1)
   at 0x401331a4: _Jv_FindClass(_Jv_Utf8Const *, java::lang::ClassLoader *)
(/usr/local/lib/libgcj.so.1)
   at 0x40130382: java::lang::Class::forName(java::lang::String *)
(/usr/local/lib/libgcj.so.1)
   at 0x40133f8a: java::lang::FirstThread::run(void) (/usr/local/lib/libgcj.so.1)
   at 0x400e20c2: java::lang::Thread::run_(void) (/usr/local/lib/libgcj.so.1)
   at 0x40139aca: java::lang::Thread::run__(java::lang::Object *)
(/usr/local/lib/libgcj.so.1)
   at 0x4014a6c2: _Jv_ThreadSetPriority(_Jv_Thread_t *, int)
(/usr/local/lib/libgcj.so.1)
   at 0x401eaf16: GC_start_routine (/usr/local/lib/libgcjgc.so.1)
   at 0x40203ccf: pthread_detach (/lib/libpthread.so.0)
   at 0x402d71ba: __clone (/lib/libc.so.6)
addr2line: /proc/10380/exe: No such file or directory

[jcej@node04 T3]$ pwd
/home2/jcej/projects/personal/gcj/T3

[jcej@node04 T3]$ echo $CLASSPATH
/home2/jcej/projects/personal/gcj/T3

[jcej@node04 T3]$ echo $LD_LIBRARY_PATH
/home2/jcej/projects/personal/gcj/T3:/usr/local/lib


If I javac HelloWorld.java then things work.  The complete example is at
http://www.lads.com/~jcej/gcj/T3/

But if I extend the example to do a CNI call then I find myself back in the same
boat.  I put the entire test case at http://www.lads.com/~jcej/gcj/T4/ in case
anyone wants to point out the error of my ways...  The file 'results' is the
output of compiling & trying to execute.

Re: gij with gcc 2.95.2 (was: Re: internal error - SP mismatch)

[James CE Johnson]

Ok...

This works:
    [jcej@node04 T3]$ rm -f *.so *.class
    [jcej@node04 T3]$ gcj -C HelloWorld.java
    [jcej@node04 T3]$ gij HelloWorld
    Hello World

As does this:
    [jcej@node04 T3]$ rm -f *.so *.class
    [jcej@node04 T3]$ gcj -shared -o HelloWorld.so HelloWorld.java
    [jcej@node04 T3]$ gij HelloWorld
    Hello World

Both of those with this trivial HelloWorld.java:
    public class HelloWorld
    {
       public static void main(String args[])
       {
          System.err.println("Hello World");
       }
    }

Now I want to simulate using an object in some random .class file.  So I create:
class Foo
{
        public int Bar()
        {
                System.err.println("Foo::Bar");
                return 0;
        }
}

And change main():
public class HelloWorld
{
   public static void main(String args[])
   {
      System.err.println("Hello World");
      Foo foo = new Foo();
      foo.Bar();
   }
}

Compile everything to .class and we have success:

[jcej@node04 T3]$ rm -f *.so *.class
[jcej@node04 T3]$ gcj -C HelloWorld.java
[jcej@node04 T3]$ gcj -C Foo.java
[jcej@node04 T3]$ gij HelloWorld
Hello World
Foo::Bar

Try mixing native binary & .class and we have failure:

[jcej@node04 T3]$ rm -f *.so *.class
[jcej@node04 T3]$ gcj -C Foo.java
[jcej@node04 T3]$ gcj -shared -o HelloWorld.so HelloWorld.java
[jcej@node04 T3]$ gij HelloWorld
java.lang.ClassNotFoundException: HelloWorld
   at 0x400e4e4b: java::lang::Throwable::Throwable(java::lang::String *)
(/usr/local/lib/libgcj.so.1)
   at 0x400d8984: java::lang::Exception::Exception(java::lang::String *)
(/usr/local/lib/libgcj.so.1)
   at 0x400d7cf4:
java::lang::ClassNotFoundException::ClassNotFoundException(java::lang::String *)
(/usr/local/lib/libgcj.so.1)
   at 0x400fcc44: java::net::URLClassLoader::findClass(java::lang::String *)
(/usr/local/lib/libgcj.so.1)
   at 0x400d71d6: java::lang::ClassLoader::loadClass(java::lang::String *, bool)
(/usr/local/lib/libgcj.so.1)
   at 0x401331a4: _Jv_FindClass(_Jv_Utf8Const *, java::lang::ClassLoader *)
(/usr/local/lib/libgcj.so.1)
   at 0x40130382: java::lang::Class::forName(java::lang::String *)
(/usr/local/lib/libgcj.so.1)
   at 0x40133f8a: java::lang::FirstThread::run(void) (/usr/local/lib/libgcj.so.1)
   at 0x400e20c2: java::lang::Thread::run_(void) (/usr/local/lib/libgcj.so.1)
   at 0x40139aca: java::lang::Thread::run__(java::lang::Object *)
(/usr/local/lib/libgcj.so.1)
   at 0x4014a6c2: _Jv_ThreadSetPriority(_Jv_Thread_t *, int)
(/usr/local/lib/libgcj.so.1)
   at 0x401eaf16: GC_start_routine (/usr/local/lib/libgcjgc.so.1)
   at 0x40203ccf: pthread_detach (/lib/libpthread.so.0)
   at 0x402d71ba: __clone (/lib/libc.so.6)

[jcej@node04 T3]$ pwd
/home2/jcej/projects/personal/gcj/T3

[jcej@node04 T3]$ echo $CLASSPATH
/home2/jcej/projects/personal/gcj/T3

[jcej@node04 T3]$ echo $LD_LIBRARY_PATH
/home2/jcej/projects/personal/gcj/T3:/usr/local/lib


So... What did I do wrong this time?

Re: CNI invocation [was Re: Segfault on simple HelloWorld]

[Tom Tromey]

Bryce> For now, you could try using JNI (supported in current libgcj
Bryce> snapshots), or create a simple java "main" class to call your
Bryce> C++ main method, and link your application using "gcj
Bryce> --main=xxx". In fact, "public static native void main(String
Bryce> args[])" should probibly work ;-)

If you're going to make a native Foo.main() you could just make it use
CNI.

Our JNI includes an invocation interface, but it has never been tested
and, I would venture, almost certainly has bugs.  My JNI testing has
been (temporarily) derailed by other work.

Tom

Segfault on simple HelloWorld

[James CE Johnson]

Forgive the newcomer...

I'm interested in using Java classes from my C++ app.  I just tripped
across gcj a few weeks ago & started messing with it.  The simple test
case I have below segfaults.

[jcej@node04 tmp]$ cat Makefile

INCLDIR  = -I
$(HOME)/ThirdParty/objdir/i686-pc-linux-gnu/libjava/include
INCLDIR += -I $(HOME)/ThirdParty/libgcj-2.95.1/libjava/include
INCLDIR += -I $(HOME)/ThirdParty/libgcj-2.95.1/libjava

run : Test
        LD_LIBRARY_PATH=/usr/local/lib ./Test

gdb : Test
        LD_LIBRARY_PATH=/usr/local/lib gdb ./Test

Test : main.o Test.o
        gcj -o Test main.o Test.o

main.o : main.cpp Test.h
        g++ $(INCLDIR) -c main.cpp

Test.class : Test.java
        javac -classpath . Test.java

Test.h : Test.class
        gcjh --classpath . Test

Test.o : Test.class
        gcj -c Test.class

clean realclean :
        rm -f Test.o main.o Test.h Test.class Test

[jcej@node04 tmp]$ cat main.cpp

#include "Test.h"

int main(int,char**)
{
        Test * test = new Test();

        test->HelloWorld(); // This is line 8

        delete test;

        return 0;
}

[jcej@node04 tmp]$ cat Test.java

public class Test
{
    public int HelloWorld()
    {
        System.out.println("Hello World");
        return 0; // This is line 7
    }
}

[jcej@node04 tmp]$ make gdb
javac -classpath . Test.java
gcjh --classpath . Test
g++ -I /home2/jcej/ThirdParty/objdir/i686-pc-linux-gnu/libjava/include
-I /home2
/jcej/ThirdParty/libgcj-2.95.1/libjava/include -I
/home2/jcej/ThirdParty/libgcj-
2.95.1/libjava -c main.cpp
gcj -c Test.class
gcj -o Test main.o Test.o
LD_LIBRARY_PATH=/usr/local/lib gdb ./Test
GNU gdb 4.17
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i586-pc-linux-gnu"...
(gdb) run
Starting program: /home2/jcej/tmp/./Test
Hello World

Program received signal SIGSEGV, Segmentation fault.
0x400b3844 in java::lang::Thread::interrupted ()
    at
/home2/jcej/ThirdParty/libgcj-2.95.1/libjava/java/lang/Thread.java:276
276       }
Current language:  auto; currently java
(gdb) bt
#0  0x400b3844 in java::lang::Thread::interrupted ()
    at
/home2/jcej/ThirdParty/libgcj-2.95.1/libjava/java/lang/Thread.java:276
#1  0x400ebfae in java::io::FileDescriptor::write ()
    at java/io/natFileDescriptor.cc:232
#2  0x4009b1c0 in java::io::FileOutputStream::write ()
    at
/home2/jcej/ThirdParty/libgcj-2.95.1/libjava/java/io/FileOutputStream.jav

a:34
#3  0x40094043 in java::io::BufferedOutputStream::flush ()
    at
/home2/jcej/ThirdParty/libgcj-2.95.1/libjava/java/io/BufferedOutputStream

.java:70
#4  0x400a0ddd in java::io::PrintStream::flush ()
    at
/home2/jcej/ThirdParty/libgcj-2.95.1/libjava/java/io/PrintStream.java:90

#5  0x400a0efc in java::io::PrintStream::print ()
    at
/home2/jcej/ThirdParty/libgcj-2.95.1/libjava/java/io/PrintStream.java:90

#6  0x400a19b5 in java::io::PrintStream::println ()
    at
/home2/jcej/ThirdParty/libgcj-2.95.1/libjava/java/io/PrintStream.java:90

#7  0x804ad9e in Test.HelloWorld ()
#8  0x804ad14 in main ()
#9  0x401dfa12 in __libc_start_main ()
(gdb) The program is running.  Exit anyway? (y or n) y

Re: Threads [was Re: internal error - SP mismatch]

[Matt Welsh]

Bryce McKinlay <bryce@albatross.co.nz> writes:
> Matt, can I ask you to try my new posix-threads patch at:
> 
>  http://sourceware.cygnus.com/ml/java-patches/2000-q1/msg00248.html

You are my hero :-) I will try them out when I get back later this week.
 
> There are definatly some nasty threads bugs in the current libgcj, 

That would really help explain what I'm seeing now. Thanks!!

Matt

Re: internal error - SP mismatch

[Tom Tromey]

Jeff> - get a gcc snapshot (and cross your fingers... recent snapshots
Jeff>   are notoriously unstable)

Before you try this, note that gcc hasn't been able to build libgcj
for about 2 weeks.  Right now the development gcc can't even bootstrap
on x86.  So don't waste any time downloading gcc -- you'll just be
frustrated (like me :-).  If you can find a slightly older snapshot,
that might work.  Of course, then you'll be missing some of Alex's
improvements to the Java front end.  Sigh.

Tom

Re: internal error - SP mismatch

[Matt Welsh]

Tom Tromey <tromey@cygnus.com> writes:
> Matt> Or, you can try using gcc-2.95.2 with the latest libgcj *and*
> Matt> the patches from Bryce at:
> 
> I thought this had problems with the new exception-handling stuff that
> libgcj assumes is in the C++ front end :-(

Ah, you're right. I'm not using the latest libgcj -- I'm using the one
just before the CNI catch changes were put in.

> Sure.  Could you write a patch against the web page?  

I can do that, but what I think we really need is a "current status" page
which says "The current stable version is X, but the following newer versions
have been used as well..."

I'll write up a skeleton of this webpage and send it to you.

Matt