jamvm-general — General discussion of the Jam Virtual Machine.

RE: [Jamvm-general] Re: jamvm + classpath CVS

[Jeroen F. <je...@su...>]

Robert Lougher wrote:
> P.S.  It's the System.arraycopy in String.getChars that triggers
> System.<clinit>.

Yes, thanks for researching this. I shouldn't have changed String to
call VMSystem.arraycopy directly, to avoid initializing System.

I'll write a patch.

Regards,
Jeroen

Re: [Jamvm-general] Re: jamvm + classpath CVS

[Robert L. <rob...@gm...>]

Sorry, when I said Runtime.<clinit> I meant Runtime.<init>.

Rob.

P.S.  It's the System.arraycopy in String.getChars that triggers
System.<clinit>.

> This is a trace showing the sequence which triggers the recursive
> initialisation.  As discussed above, in Runtime.<clinit> we end up
> with a null pointer because SystemProperties is initialised
> recursively.  This causes the whole Classpath initialisation sequence
> to fail.
> 
> <<<<<<< LEAVING NOW BACK IN gnu/classpath/SystemProperties.<clinit>()V
> >>>>>>> ENTERING java/lang/StringBuffer.<init>(Ljava/lang/String;)V
> >>>>>>>> ENTERING java/lang/Object.<init>()V
> <<<<<<<< LEAVING NOW BACK IN java/lang/StringBuffer.<init>(Ljava/lang/String;)V
> >>>>>>>> ENTERING java/lang/String.getChars(II[CI)V
> >>>>>>>>>ENTERED java/lang/System.<clinit>()V
> >>>>>>>>>> ENTERING
> java/lang/VMSystem.makeStandardInputStream()Ljava/io/InputStream;
> >>>>>>>>>>>ENTERED java/io/FileDescriptor.<clinit>()V
> >>>>>>>>>>>>ENTERED gnu/java/nio/channels/FileChannelImpl.<clinit>()V
> >>>>>>>>>>>>> ENTERING java/lang/System.loadLibrary(Ljava/lang/String;)V
> >>>>>>>>>>>>>>ENTERED java/lang/Runtime.<clinit>()V
> >>>>>>>>>>>>>>>> ENTERING java/lang/Object.<init>()V
> <<<<<<<<<<<<<<<< LEAVING NOW BACK IN java/lang/Runtime.<init>()V
> RECURSIVELY INITING BY ME!!!!!!!!!!!!!! gnu/classpath/SystemProperties
> >>>>>>>>>>>>>>>> ENTERING
> gnu/classpath/SystemProperties.getProperty(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
> RECURSIVELY INITING BY ME!!!!!!!!!!!!!! gnu/classpath/SystemProperties
> >>>>>>>>>>>>>>>>>ENTERED
> java/lang/NullPointerException.<init>(Ljava/lang/String;)V
> 
> CC-ing to the Classpath list in case any other VM implementor is
> having problems with this.
> 
> Now that JamVM is working with classpath cvs again, I'll put together a patch.
> 
> Thanks,
> 
> Rob.
>

Re: [Jamvm-general] Re: jamvm + classpath CVS

[Robert L. <rob...@gm...>]

On Thu, 9 Dec 2004 15:51:05 +0100, Jeroen Frijters <je...@su...> wrote:
> Michael Koch wrote:
> 
> 
> > Am Donnerstag, 9. Dezember 2004 14:32 schrieb Robert Lougher:
> > > Hi Michael,
> > >
> > > By the time I downloaded classpath cvs and builit it, I didn't have
> > > long to work on this.  I put in the native methods, and modified
> > > the VM classes.  I'm now getting stuck in a recursive class
> > > initialisation dependency.  I've not investigated it very far, but
> > > it appears that SystemProperties.<clinit> forces Runtime.<clinit>,
> > > which uses SystemProperties -- as it's being initialised, we return
> > > (step 3 of initialisation process), accessing properties, which is
> > > null (hence the NullPointerException).  BTW, it ends up as a
> > > NoClassDefError because Runtime gets marked as bad.
> > >
> > > I'll have a look at it again tonight.  Did you manage to get past
> > > this stage?  I may post something onto the classpath list but I
> > > want to make sure I've not done anything stupid first :)
> > > 
> > > Rob.
> >
> > I hit the same problem. I thought it was me doing something
> > stupd with the native methods. I think I concluded wrong.
> >
> > I CC'ed Jeroen now as he wrote the patch. Perhaps he can say
> > something
> > about this.
> >
> > Jeroen: I think we have a problem with initialization in GNU
> > classpath. Can you tell us something about the above ?
> 
> Can you figure out why SystemProperties is initializing Runtime? That
> doesn't happen for me (and it shouldn't happen).
> 
> Regards,
> Jeroen
>

Hi,

It is a problem with SystemProperties.<clinit>.  It's triggered when
StringBuffer is used.  In my case this happens because my native
preInit() doesn't define "http.agent", so it sets up a default one,
using a StringBuffer.  You probably define this property yourself so
you don't see it.  Setting http.agent in preInit() fixes the problem
with JamVM.

This is a trace showing the sequence which triggers the recursive
initialisation.  As discussed above, in Runtime.<clinit> we end up
with a null pointer because SystemProperties is initialised
recursively.  This causes the whole Classpath initialisation sequence
to fail.

<<<<<<< LEAVING NOW BACK IN gnu/classpath/SystemProperties.<clinit>()V
>>>>>>> ENTERING java/lang/StringBuffer.<init>(Ljava/lang/String;)V
>>>>>>>> ENTERING java/lang/Object.<init>()V
<<<<<<<< LEAVING NOW BACK IN java/lang/StringBuffer.<init>(Ljava/lang/String;)V
>>>>>>>> ENTERING java/lang/String.getChars(II[CI)V
>>>>>>>>>ENTERED java/lang/System.<clinit>()V
>>>>>>>>>> ENTERING
java/lang/VMSystem.makeStandardInputStream()Ljava/io/InputStream;
>>>>>>>>>>>ENTERED java/io/FileDescriptor.<clinit>()V
>>>>>>>>>>>>ENTERED gnu/java/nio/channels/FileChannelImpl.<clinit>()V
>>>>>>>>>>>>> ENTERING java/lang/System.loadLibrary(Ljava/lang/String;)V
>>>>>>>>>>>>>>ENTERED java/lang/Runtime.<clinit>()V
>>>>>>>>>>>>>>>> ENTERING java/lang/Object.<init>()V
<<<<<<<<<<<<<<<< LEAVING NOW BACK IN java/lang/Runtime.<init>()V
RECURSIVELY INITING BY ME!!!!!!!!!!!!!! gnu/classpath/SystemProperties
>>>>>>>>>>>>>>>> ENTERING
gnu/classpath/SystemProperties.getProperty(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
RECURSIVELY INITING BY ME!!!!!!!!!!!!!! gnu/classpath/SystemProperties
>>>>>>>>>>>>>>>>>ENTERED
java/lang/NullPointerException.<init>(Ljava/lang/String;)V

CC-ing to the Classpath list in case any other VM implementor is
having problems with this.

Now that JamVM is working with classpath cvs again, I'll put together a patch.

Thanks,

Rob.

Re: [Jamvm-general] Re: jamvm + classpath CVS

[Mark W. <ma...@kl...>]

On Thu, 2004-12-09 at 16:00, Robert Lougher wrote:
> > > Jeroen: I think we have a problem with initialization in GNU
> > > classpath. Can you tell us something about the above ?
> >=20
> > Can you figure out why SystemProperties is initializing Runtime? That
> > doesn't happen for me (and it shouldn't happen).
>
> That's what I was planning to do tonight.  I got as far as determining
> it wasn't the properties.put and had to leave it there.

I looked a bit into it and it is rather difficult to fix this.
First I tried to just make a default implementation of
VMSystemProperties, but adding System.loadLibrary() to the mix to
provide a default implementation fails horribly. Some of the default VM
interface classes depend on being able to call System.loadLibrary() in
their static initializers. Also notice that you don't want VMClassLoader
to access java.lang.System anymore for properties during early load. You
really need to use the GNU Classpath supplied java.lang.ClassLoader (or
make sure that your override ClassLoader has the same initialization
sequence as that one). And that VMRuntime.nativeGetLibname() has been
removed and renamed to mapLibraryName().

I have given up on comming up with something that will help runtimes
based on 0.12 to just work. Will try tomorrow to come up with a good
description on how initialization has changed and how to handle the
System.loadLibrary() stuff during early bootstrap. But I don't have a
good idea how to really handle this at the moment. Maybe it is simple,
but I am too tired now to see how the bootstrap sequence is supposed to
play out and what a VM interface class can and cannot use during
initialization.

Cheers,

Mark

Re: [Jamvm-general] Re: jamvm + classpath CVS

[Robert L. <rob...@gm...>]

> > Jeroen: I think we have a problem with initialization in GNU
> > classpath. Can you tell us something about the above ?
> 
> Can you figure out why SystemProperties is initializing Runtime? That
> doesn't happen for me (and it shouldn't happen).
> 
> Regards,
> Jeroen
> 

That's what I was planning to do tonight.  I got as far as determining
it wasn't the properties.put and had to leave it there.

Rob.

RE: [Jamvm-general] Re: jamvm + classpath CVS

[Jeroen F. <je...@su...>]

Michael Koch wrote:
> Am Donnerstag, 9. Dezember 2004 14:32 schrieb Robert Lougher:
> > Hi Michael,
> >
> > By the time I downloaded classpath cvs and builit it, I didn't have
> > long to work on this.  I put in the native methods, and modified
> > the VM classes.  I'm now getting stuck in a recursive class
> > initialisation dependency.  I've not investigated it very far, but
> > it appears that SystemProperties.<clinit> forces Runtime.<clinit>,
> > which uses SystemProperties -- as it's being initialised, we return
> > (step 3 of initialisation process), accessing properties, which is
> > null (hence the NullPointerException).  BTW, it ends up as a
> > NoClassDefError because Runtime gets marked as bad.
> >
> > I'll have a look at it again tonight.  Did you manage to get past
> > this stage?  I may post something onto the classpath list but I
> > want to make sure I've not done anything stupid first :)
>=20
> I hit the same problem. I thought it was me doing something=20
> stupd with the native methods. I think I concluded wrong.
>=20
> I CC'ed Jeroen now as he wrote the patch. Perhaps he can say=20
> something=20
> about this.
>=20
> Jeroen: I think we have a problem with initialization in GNU=20
> classpath. Can you tell us something about the above ?

Can you figure out why SystemProperties is initializing Runtime? That
doesn't happen for me (and it shouldn't happen).

Regards,
Jeroen

Re: [Jamvm-general] Re: jamvm + classpath CVS

[Robert L. <rob...@gm...>]

Thanks Michael.


On Thu, 9 Dec 2004 15:24:20 +0100, Michael Koch <kon...@gm...> wrote:
> Am Donnerstag, 9. Dezember 2004 14:32 schrieb Robert Lougher:
> 
> 
> > Hi Michael,
> >
> > By the time I downloaded classpath cvs and builit it, I didn't have
> > long to work on this.  I put in the native methods, and modified
> > the VM classes.  I'm now getting stuck in a recursive class
> > initialisation dependency.  I've not investigated it very far, but
> > it appears that SystemProperties.<clinit> forces Runtime.<clinit>,
> > which uses SystemProperties -- as it's being initialised, we return
> > (step 3 of initialisation process), accessing properties, which is
> > null (hence the NullPointerException).  BTW, it ends up as a
> > NoClassDefError because Runtime gets marked as bad.
> >
> > I'll have a look at it again tonight.  Did you manage to get past
> > this stage?  I may post something onto the classpath list but I
> > want to make sure I've not done anything stupid first :)
> 
> I hit the same problem. I thought it was me doing something stupd with
> the native methods. I think I concluded wrong.
> 
> I CC'ed Jeroen now as he wrote the patch. Perhaps he can say something
> about this.
> 
> Jeroen: I think we have a problem with initialization in GNU
> classpath. Can you tell us something about the above ?
> 
> 
> 
> 
> Michael
> --
> Homepage: http://www.worldforge.org/
>

Re: [Jamvm-general] Re: jamvm + classpath CVS

[Michael K. <kon...@gm...>]

Am Donnerstag, 9. Dezember 2004 14:32 schrieb Robert Lougher:
> Hi Michael,
>
> By the time I downloaded classpath cvs and builit it, I didn't have
> long to work on this.  I put in the native methods, and modified
> the VM classes.  I'm now getting stuck in a recursive class
> initialisation dependency.  I've not investigated it very far, but
> it appears that SystemProperties.<clinit> forces Runtime.<clinit>,
> which uses SystemProperties -- as it's being initialised, we return
> (step 3 of initialisation process), accessing properties, which is
> null (hence the NullPointerException).  BTW, it ends up as a
> NoClassDefError because Runtime gets marked as bad.
>
> I'll have a look at it again tonight.  Did you manage to get past
> this stage?  I may post something onto the classpath list but I
> want to make sure I've not done anything stupid first :)

I hit the same problem. I thought it was me doing something stupd with 
the native methods. I think I concluded wrong.

I CC'ed Jeroen now as he wrote the patch. Perhaps he can say something 
about this.

Jeroen: I think we have a problem with initialization in GNU 
classpath. Can you tell us something about the above ?


Michael
-- 
Homepage: http://www.worldforge.org/

Re: [Jamvm-general] Re: jamvm + classpath CVS

[Robert L. <rob...@gm...>]

Hi Michael,

By the time I downloaded classpath cvs and builit it, I didn't have
long to work on this.  I put in the native methods, and modified the
VM classes.  I'm now getting stuck in a recursive class initialisation
dependency.  I've not investigated it very far, but it appears that
SystemProperties.<clinit> forces Runtime.<clinit>, which uses
SystemProperties -- as it's being initialised, we return (step 3 of
initialisation process), accessing properties, which is null (hence
the NullPointerException).  BTW, it ends up as a NoClassDefError
because Runtime gets marked as bad.

I'll have a look at it again tonight.  Did you manage to get past this
stage?  I may post something onto the classpath list but I want to
make sure I've not done anything stupid first :)

Thanks,

Rob.

On Wed, 8 Dec 2004 22:00:59 +0000, Robert Lougher <rob...@gm...> wrote:
> Hi Michael,
> 
> OK, I'll work on it now.  I don't have classpath CVS, so I'll to get it...
> 
> Thanks,
> 
> Rob.
> 
> P.S.  I expect your patch was fine.  I only _think_ it's possible to
> get one that'll work with both.  It could be wishful thinking :)
> 
> 
> 
> On Wed, 8 Dec 2004 21:39:39 +0100, Michael Koch <kon...@gm...> wrote:
> > Am Mittwoch, 8. Dezember 2004 15:01 schrieb Robert Lougher:
> > > There's also changes to the reference VMClassLoader, but I don't
> > > think these affect JamVM as it uses it's own native implementation
> > > of getResources.
> > >
> > > From the looks of it, it should be possible to get a patch so that
> > > the same version will run with Classpath-0.12 and CVS.
> >
> > I think the solution I worked is somehow bad. And it will definitely
> > not work with CP 0.12. Can you try to provide a patch ?
> >
> >
> >
> >
> > Michael
> > --
> > Homepage: http://www.worldforge.org/
> >
>

Re: [Jamvm-general] Re: jamvm + classpath CVS

[Michael K. <kon...@gm...>]

Am Mittwoch, 8. Dezember 2004 15:01 schrieb Robert Lougher:
> There's also changes to the reference VMClassLoader, but I don't
> think these affect JamVM as it uses it's own native implementation
> of getResources.
>
> From the looks of it, it should be possible to get a patch so that
> the same version will run with Classpath-0.12 and CVS.

I think the solution I worked is somehow bad. And it will definitely 
not work with CP 0.12. Can you try to provide a patch ?


Michael
-- 
Homepage: http://www.worldforge.org/

Re: [Jamvm-general] Re: jamvm + classpath CVS

[Michael K. <kon...@gm...>]

Am Mittwoch, 8. Dezember 2004 13:59 schrieb Robert Lougher:
> On Wed, 8 Dec 2004 13:28:50 +0100, Michael Koch <kon...@gm...> 
wrote:
> > Am Mittwoch, 8. Dezember 2004 13:23 schrieb Robert Lougher:
> > > Hi Michael,
> > >
> > > As a matter of interest, when did jamvm + classpath CVS break? 
> > > Any idea what the change could have been?
> >
> > Two days ago when Jeroen commited his SystemProperties patch.
>
> Wonderful.  I'll look back at the proposed patch and see what it
> does. I haven't been taking much notice, but I didn't think it
> required VM changes.  I would have expected some warnings and a
> FULL description of the changes needed if it did -- not just drop
> it in, and bugger everybody else.

Well, it was there. on classpath-patches and inside the NEWS file.
I have jamvm running again, thanks to your help. I need to cleanup the 
patch and will post it here.


Michael
-- 
Homepage: http://www.worldforge.org/

Re: [Jamvm-general] Re: jamvm + classpath CVS

[Michael K. <kon...@gm...>]

Am Mittwoch, 8. Dezember 2004 13:23 schrieb Robert Lougher:
> Hi Michael,
>
> As a matter of interest, when did jamvm + classpath CVS break?  Any
> idea what the change could have been?

Two days ago when Jeroen commited his SystemProperties patch.


Michael
-- 
Homepage: http://www.worldforge.org/

Re: [Jamvm-general] Re: jamvm + classpath CVS

[Robert L. <rob...@gm...>]

Hi Michael,

OK, I'll work on it now.  I don't have classpath CVS, so I'll to get it...

Thanks,

Rob.

P.S.  I expect your patch was fine.  I only _think_ it's possible to
get one that'll work with both.  It could be wishful thinking :)

On Wed, 8 Dec 2004 21:39:39 +0100, Michael Koch <kon...@gm...> wrote:
> Am Mittwoch, 8. Dezember 2004 15:01 schrieb Robert Lougher:
> > There's also changes to the reference VMClassLoader, but I don't
> > think these affect JamVM as it uses it's own native implementation
> > of getResources.
> >
> > From the looks of it, it should be possible to get a patch so that
> > the same version will run with Classpath-0.12 and CVS.
> 
> I think the solution I worked is somehow bad. And it will definitely
> not work with CP 0.12. Can you try to provide a patch ?
> 
> 
> 
> 
> Michael
> --
> Homepage: http://www.worldforge.org/
>

Re: [Jamvm-general] Re: jamvm + classpath CVS

[Michael K. <kon...@gm...>]

Am Mittwoch, 8. Dezember 2004 14:41 schrieb Robert Lougher:
> The problem is I don't have access to CVS during the week...  From
> looking at the patch, it needs
>
> 1) Update to JamVM's ClassLoader class (or remove it, and use
> Classpath's one)
>
> 2) Implement VMSystemProperties init() and isWordsBigEndian(). 
> From the looks of it, you can use the existing
> insertSystemProperties for init().
>
> Is this what you've done?

yes, and some stuff more.


Michael
-- 
Homepage: http://www.worldforge.org/

Re: [Jamvm-general] Re: jamvm + classpath CVS

[Robert L. <rob...@gm...>]

There's also changes to the reference VMClassLoader, but I don't think
these affect JamVM as it uses it's own native implementation of
getResources.

From the looks of it, it should be possible to get a patch so that the
same version will run with Classpath-0.12 and CVS.

Thanks,

Rob.

On Wed, 8 Dec 2004 14:53:38 +0100, Michael Koch <kon...@gm...> wrote:
> Am Mittwoch, 8. Dezember 2004 14:41 schrieb Robert Lougher:
> 
> 
> > The problem is I don't have access to CVS during the week...  From
> > looking at the patch, it needs
> >
> > 1) Update to JamVM's ClassLoader class (or remove it, and use
> > Classpath's one)
> >
> > 2) Implement VMSystemProperties init() and isWordsBigEndian().
> > From the looks of it, you can use the existing
> > insertSystemProperties for init().
> >
> > Is this what you've done?
> 
> yes, and some stuff more.
> 
> 
> 
> 
> Michael
> --
> Homepage: http://www.worldforge.org/
>

Re: [Jamvm-general] Re: jamvm + classpath CVS

[Robert L. <rob...@gm...>]

The problem is I don't have access to CVS during the week...  From
looking at the patch, it needs

1) Update to JamVM's ClassLoader class (or remove it, and use Classpath's one)

2) Implement VMSystemProperties init() and isWordsBigEndian().  From
the looks of it, you can use the existing insertSystemProperties for
init().

Is this what you've done?

Rob.

On Wed, 8 Dec 2004 14:02:08 +0100, Michael Koch <kon...@gm...> wrote:
> Am Mittwoch, 8. Dezember 2004 13:59 schrieb Robert Lougher:
> 
> 
> > On Wed, 8 Dec 2004 13:28:50 +0100, Michael Koch <kon...@gm...>
> wrote:
> > > Am Mittwoch, 8. Dezember 2004 13:23 schrieb Robert Lougher:
> > > > Hi Michael,
> > > >
> > > > As a matter of interest, when did jamvm + classpath CVS break?
> > > > Any idea what the change could have been?
> > >
> > > Two days ago when Jeroen commited his SystemProperties patch.
> >
> > Wonderful.  I'll look back at the proposed patch and see what it
> > does. I haven't been taking much notice, but I didn't think it
> > required VM changes.  I would have expected some warnings and a
> > FULL description of the changes needed if it did -- not just drop
> > it in, and bugger everybody else.
> 
> Well, it was there. on classpath-patches and inside the NEWS file.
> I have jamvm running again, thanks to your help. I need to cleanup the
> patch and will post it here.
> 
> 
> 
> 
> Michael
> --
> Homepage: http://www.worldforge.org/
>

Re: [Jamvm-general] Re: jamvm + classpath CVS

[Robert L. <rob...@gm...>]

On Wed, 8 Dec 2004 13:28:50 +0100, Michael Koch <kon...@gm...> wrote:
> Am Mittwoch, 8. Dezember 2004 13:23 schrieb Robert Lougher:
> > Hi Michael,
> >
> > As a matter of interest, when did jamvm + classpath CVS break?  Any
> > idea what the change could have been?
> 
> Two days ago when Jeroen commited his SystemProperties patch.
> 

Wonderful.  I'll look back at the proposed patch and see what it does.
 I haven't been taking much notice, but I didn't think it required VM
changes.  I would have expected some warnings and a FULL description
of the changes needed if it did -- not just drop it in, and bugger
everybody else.

Rob.

> Michael
> --
> 
> 
> Homepage: http://www.worldforge.org/
>

[Jamvm-general] Re: jamvm + classpath CVS

[Robert L. <rob...@gm...>]

Hi Michael,

As a matter of interest, when did jamvm + classpath CVS break?  Any
idea what the change could have been?

Thanks,

Rob.

On Wed, 8 Dec 2004 09:56:46 +0100, Michael Koch <kon...@gm...> wrote:
> Hi Robert,
> 
> I just try to write a patch to make jamvm work with latest classpath
> CVS. It's based on jamvm 1.2.1.
> 
> My problem is now that I get a NullPointerException when
> java.lang.Runtime gets used during startup.
> 
> When starting jamvm with a simple HelloWorld app I get the following:
> 
> Cannot create system class loader
> Exception occured while printing exception
> (java/lang/NoClassDefFoundError)...
> Original exception was java/lang/ExceptionInInitializerError
> 
> With "jamvm -verbose HelloWorld" I saw that the last class access
> before the lang.lang.NullPointerException was loaded is
> java.lang.Runtime.
> 
> How can I find out in which method in java.lang.Runtime this occurs ?
> I know this class gets used before and was already initialized.
> Any tipps for debugging ?
> 
> Michael
> 
> P.S.: To get this far I did already some changes to jamvm. I will send
> a patch to you soon.
> --
> Homepage: http://www.worldforge.org/
>

[Jamvm-general] Re: jamvm + classpath CVS

[Robert L. <rob...@gm...>]

Hi Michael,

It should be quite easy, but you'll have to use gdb :(

1) When debugging a C program it's always better to compile it with no
optimisation.  Reconfigure jamvm (CFLAGS=-g ./configure) and
rebuild...

2) Do gdb jamvm

3) In gdb enter :

handle SIGUSR1 nostop noprint pass

(this stops gdb interfering with jamvm's thread suspension mechanism)

4) Assuming the NullPointer is thrown by the VM due to a null pointer
access (as opposed to a throw in Java).  Put a breakpoint on
signalException :

break signalException

5) type "run HelloWorld"

6) Hopefully you'll hit the breakpoint.  From the parameters
(excep_name) you should be able to see what exception is being
signalled.

7) To find out where you are, do "bt".  This will print a backtrace of
the C functions on the call stack.  Assuming signalException has been
called from the interpreter, the previous function should be
"executeJava".

8) Do "up" to move to the previous call frame (i.e. the interpreter). 
In here type:

print mb->name

This will print out the name of the currently executing method.

To find the class, do:

print ((ClassBlock*)(mb->class+1))->name

If you want, you can follow the Java call stack :

frame points to the last frame on the thread's Java stack.

frame->prev->mb->name

Shows the name of the method which called this one.

There are a couple of special frames to handle linkage between native
code and Java, etc. so this trick won't work for all frames...

Hope this helps,

Rob.

On Wed, 8 Dec 2004 09:56:46 +0100, Michael Koch <kon...@gm...> wrote:
> Hi Robert,
> 
> I just try to write a patch to make jamvm work with latest classpath
> CVS. It's based on jamvm 1.2.1.
> 
> My problem is now that I get a NullPointerException when
> java.lang.Runtime gets used during startup.
> 
> When starting jamvm with a simple HelloWorld app I get the following:
> 
> Cannot create system class loader
> Exception occured while printing exception
> (java/lang/NoClassDefFoundError)...
> Original exception was java/lang/ExceptionInInitializerError
> 
> With "jamvm -verbose HelloWorld" I saw that the last class access
> before the lang.lang.NullPointerException was loaded is
> java.lang.Runtime.
> 
> How can I find out in which method in java.lang.Runtime this occurs ?
> I know this class gets used before and was already initialized.
> Any tipps for debugging ?
> 
> Michael
> 
> P.S.: To get this far I did already some changes to jamvm. I will send
> a patch to you soon.
> --
> Homepage: http://www.worldforge.org/
>

Re: [Jamvm-general] softfloat with jamvm 1.2.1

[Robert L. <rob...@gm...>]

Hi,

I see you've found the mailing list :)

The ARM changes in 1.2.1 is based on a couple of patches I did for
people using Big-Endian and soft floating point.  The feedback I got
is that everything worked OK.  To release it, I found a couple of
#defines I could use to wrap them in so that the correct code would be
compiled.  Looks like this is wrong -- I don't have access to the
different machines so it was all untested.

What is the Endianness of your machine?  Doubles on LE using the
kernel emulator are mixed endian, and are pure endian on BE (soft-fp
or kernel).  I guessed they were pure endian on LE using soft-fp. 
This may be what is wrong.

In src/arm/class_md.h could you try both definitions of READ_DBL (#if
0 the other out).  If __SOFTFP__ is defined (it should be) you will be
using the first.  Let me know if this works.

Thanks,

Rob.

On Tue, 07 Dec 2004 21:55:00 +0100, Dirk Opfer <di...@op...> wrote:
> Hi Robert,
> 
> Many thanks for your new version with softfloat support on arm.
> I tried this version today and found some strange things:
> 
> 1. src/arm/class_md.h needs an #endif at the end
> 2. There a problems with doubles. I wrote a java class with only
> System.out.println(0.2); After execution jamvm prints -L.0E-185
> Maybe this is a problem with endianess on double?
> Jamvm compiled with 3.4.3 (softfloat) is running on an Intel StrongArm.
> 
> Any hints to solve the problem?
> 
> Best regards,
> Dirk
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Jamvm-general mailing list
> Jam...@li...
> https://lists.sourceforge.net/lists/listinfo/jamvm-general
>

[Jamvm-general] jamvm + classpath CVS

[Michael K. <kon...@gm...>]

Hi Robert,


I just try to write a patch to make jamvm work with latest classpath 
CVS. It's based on jamvm 1.2.1.

My problem is now that I get a NullPointerException when 
java.lang.Runtime gets used during startup.

When starting jamvm with a simple HelloWorld app I get the following:

Cannot create system class loader
Exception occured while printing exception 
(java/lang/NoClassDefFoundError)...
Original exception was java/lang/ExceptionInInitializerError

With "jamvm -verbose HelloWorld" I saw that the last class access 
before the lang.lang.NullPointerException was loaded is 
java.lang.Runtime.

How can I find out in which method in java.lang.Runtime this occurs ?
I know this class gets used before and was already initialized.
Any tipps for debugging ?


Michael


P.S.: To get this far I did already some changes to jamvm. I will send 
a patch to you soon.
-- 
Homepage: http://www.worldforge.org/

[Jamvm-general] softfloat with jamvm 1.2.1

[Dirk O. <Di...@Op...>]

Hi Robert,

Many thanks for your new version with softfloat support on arm.
I tried this version today and found some strange things:

1. src/arm/class_md.h needs an #endif at the end 
2. There a problems with doubles. I wrote a java class with only
System.out.println(0.2); After execution jamvm prints -L.0E-185
Maybe this is a problem with endianess on double?
Jamvm compiled with 3.4.3 (softfloat) is running on an Intel StrongArm.

Any hints to solve the problem?

Best regards,
Dirk