produced .class Runtime Error

[obs...@gmail.com]

Hello all,
first of all congratulations for nestedVM, it is wicked!

Now I would need some help. I have compiled some c programs to .class
without difficulties or errors.

But on some of them I get this error at start:

Attempted to use a UnixRuntime syscall in Runtime (27)
Attempted to use a UnixRuntime syscall in Runtime (14)
Error Root 1

What does it mean? Is there a solution to make it work?

Thanks in advance!

[Joe Wilson]

> I have compiled some c programs to .class
> without difficulties or errors.
>
> But on some of them I get this error at start:
>
> Attempted to use a UnixRuntime syscall in Runtime (27)
> Attempted to use a UnixRuntime syscall in Runtime (14)
> Error Root 1
>
> What does it mean? Is there a solution to make it work?

When you're compiling the .c code to .class files you must specify which
runtime you need - regular or UNIX. Your program needs the UNIX runtime:

java -cp "$(classpath)" org.ibex.nestedvm.Compiler \
-outformat class -d build -o unixruntime ...etc...

Run "make test" or "make busyboxtest" for an example.

____________________________________________________________________________________Pinpoint customers who are looking for what you sell.
http://searchmarketing.yahoo.com/

[Brian Alliet]

On Thu, May 24, 2007 at 10:20:59PM -0000, obs...@gmail.com wrote:
> Attempted to use a UnixRuntime syscall in Runtime (27)
> Attempted to use a UnixRuntime syscall in Runtime (14)
> Error Root 1

Take a look at this:

http://wiki.brianweb.net/NestedVM/UnixRuntime

Basically there are two "runtimes" (the code that emulates the kernel)
in NestedVM. The normal runtime supports just enough to run ANSI C
code. The "UnixRuntime" supports everything else. Looks like you're
running code that requires the unixruntime. You'll need to pass the

-o unixRuntime

option on the NestedVM commandline. Try this and let us know how to
make out.

-Brian

[Brian Alliet]

Yep. what Joe said.

Thanks Joe,

-Brian

[obs...@gmail.com]

OK it works!

Thanks a lot!

[obs...@gmail.com]

Thanks a lot for the link and the help.

For those interested, I compiled a compiler (the Lisaac language
compiler) with NestedVM and it worked!

Even better, I can also compile sources with the lisaac.class into
programs that work. NestedVM is really very impressive.

Now, I tried to push the thing really far by trying to boostrap the
compiler with its byte-coded version (the lisaac compiler is written
in lisaac and outputs C code when compiling).

This time the error I get is:

org.ibex.nestedvm.Runtime$FaultException:
java.lang.NullPointerException at (unknown)

However I don't understand it at all. Does it tell you something?

By the way, if you're interested, Lisaac is a high level prototype oo
language that is as fast as optimized C code when compiled. It is also
capable of low-level programming (an OS, isaacOS, has been written in
it). Here is the link:

isaacos.com

[Brian Alliet]

On Fri, May 25, 2007 at 05:03:40PM -0000, obs...@gmail.com wrote:
> org.ibex.nestedvm.Runtime$FaultException:
> java.lang.NullPointerException at (unknown)

This is basically the NestedVM equivalent of a segfault. It is probably
a bug in the original program, however it could be a bug in NestedVM
too.

Unfortunately these kinds of bugs are really hard to track down. The
first thing I usually do is run it under the interpreter
(java org.ibex.nestedvm.Interpreter myapp.mips arg1 arg2 ...). This
will rule out a bug in the compiler (NestedVM's compiler) and will
often give you a better error message (in fact, if your binary has
debugging symbols it'll print out the line number where the segfault
occurred). Could you try this and let me know how the Interpreter
crashes (if at all).

If that still doesn't work I'll probably have to take a look at it
myself. If you could provide some instructions on how to rebuild Lisaac
and reproduce the problem that would be great.

Thanks,

-Brian

[Alexandre Chabert]

I tried with the interpreter and it did the same thing. Here is the output:

org.ibex.nestedvm.Runtime$ReadFaultException: fault at: 0x0 at 0x6d0dc: ??:0
        at org.ibex.nestedvm.Runtime.unsafeMemRead(Runtime.java :413)
        at org.ibex.nestedvm.Runtime.memRead(Runtime.java:401)
        at org.ibex.nestedvm.Interpreter.runSome(Interpreter.java:502)
        at org.ibex.nestedvm.Interpreter._execute(Interpreter.java:51)
        at org.ibex.nestedvm.Runtime.__execute(Runtime.java:506)
        at org.ibex.nestedvm.Runtime.execute(Runtime.java:523)
        at org.ibex.nestedvm.Runtime.run(Runtime.java:545)
        at org.ibex.nestedvm.Runtime.run (Runtime.java:538)
        at org.ibex.nestedvm.Interpreter.main(Interpreter.java:783)
Process exited on signal 11
Exit status: 139

Unfortunately, the second version of Lisaac isn't out yet (it should be in a week or two) so I can't provide you with the sources yet (it will be the first GPLed version). I'll be sure to provide you what is needed as soon as it is out.

Thanks a lot for your help.

2007/5/25, Brian Alliet <br...@brianweb.net>:

[Brian Alliet]

On Fri, May 25, 2007 at 10:39:09PM +0200, Alexandre Chabert wrote:
> org.ibex.nestedvm.Runtime$ReadFaultException: fault at: 0x0 at 0x6d0dc: ??:0

This helps a little. The 0x0 means the program tried to read from
address 0x0 (the null pointer). The "??:0" means it couldn't find the
file/line number from your binary. Did you build it with debugging
enabled (the -g option to ghc)?

-Brian

[Brian Alliet]

On Fri, May 25, 2007 at 04:43:16PM -0400, Brian Alliet wrote:
> file/line number from your binary. Did you build it with debugging
> enabled (the -g option to ghc)?

I've got Haskell on the brain, that should be gcc.

-Brian

[Joe Wilson]

Can you compile your C program with -g -O0 and then try it again?

If that does not work, put printf's in your C code to see exactly
where it is crashing.

--- Alexandre Chabert <obs...@gmail.com> wrote:
> I tried with the interpreter and it did the same thing. Here is the output:
>
> org.ibex.nestedvm.Runtime$ReadFaultException: fault at: 0x0 at 0x6d0dc: ??:0
> at org.ibex.nestedvm.Runtime.unsafeMemRead(Runtime.java:413)
> at org.ibex.nestedvm.Runtime.memRead(Runtime.java:401)
> at org.ibex.nestedvm.Interpreter.runSome(Interpreter.java:502)
> at org.ibex.nestedvm.Interpreter._execute(Interpreter.java:51)
> at org.ibex.nestedvm.Runtime.__execute(Runtime.java:506)
> at org.ibex.nestedvm.Runtime.execute(Runtime.java:523)
> at org.ibex.nestedvm.Runtime.run(Runtime.java:545)

> at org.ibex.nestedvm.Runtime.run(Runtime.java:538)

> at org.ibex.nestedvm.Interpreter.main(Interpreter.java:783)
> Process exited on signal 11
> Exit status: 139

____________________________________________________________________________________Get the free Yahoo! toolbar and rest assured with the added security of spyware protection.
http://new.toolbar.yahoo.com/toolbar/features/norton/index.php

[Joe Wilson]

--- Joe Wilson <deve...@yahoo.com> wrote:
> Can you compile your C program with -g -O0 and then try it again?
>
> If that does not work, put printf's in your C code to see exactly
> where it is crashing.
>
> --- Alexandre Chabert <obs...@gmail.com> wrote:
> > I tried with the interpreter and it did the same thing. Here is the output:
> >
> > org.ibex.nestedvm.Runtime$ReadFaultException: fault at: 0x0 at 0x6d0dc: ??:0

In your example, 0x0 is the memory location being addressed by your mips program
and 0x6d0dc is the instruction pointer of the mips program at the time.

Once you've recompiled your C code with -g -O0 and you run the code using the
nestedvm interpreter, you can retrieve the crashing line of C code by:

mips-unknown-elf-addr2line.exe -e your_program.mips 0x6d0dc

Unfortunately, you won't get a C stack backtrace.

> > at org.ibex.nestedvm.Runtime.unsafeMemRead(Runtime.java:413)
> > at org.ibex.nestedvm.Runtime.memRead(Runtime.java:401)
> > at org.ibex.nestedvm.Interpreter.runSome(Interpreter.java:502)
> > at org.ibex.nestedvm.Interpreter._execute(Interpreter.java:51)
> > at org.ibex.nestedvm.Runtime.__execute(Runtime.java:506)
> > at org.ibex.nestedvm.Runtime.execute(Runtime.java:523)
> > at org.ibex.nestedvm.Runtime.run(Runtime.java:545)
> > at org.ibex.nestedvm.Runtime.run(Runtime.java:538)
> > at org.ibex.nestedvm.Interpreter.main(Interpreter.java:783)
> > Process exited on signal 11
> > Exit status: 139

____________________________________________________________________________________Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7

[Joe Wilson]

> Once you've recompiled your C code with -g -O0 and you run the code using the
> nestedvm interpreter, you can retrieve the crashing line of C code by:
>
> mips-unknown-elf-addr2line.exe -e your_program.mips 0x6d0dc

My mistake, you do not need addr2line if you've compiled with -g
- the nestedvm interpreter will show you the same information.

For example:

org.ibex.nestedvm.Runtime$ReadFaultException: fault at: 0x12d687 at 0x11820: src/tests/Test.c:23
at org.ibex.nestedvm.Runtime.memRead(Runtime.java:400)

at org.ibex.nestedvm.Interpreter.runSome(Interpreter.java:502)
at org.ibex.nestedvm.Interpreter._execute(Interpreter.java:51)
at org.ibex.nestedvm.Runtime.__execute(Runtime.java:506)
at org.ibex.nestedvm.Runtime.execute(Runtime.java:523)
at org.ibex.nestedvm.Runtime.run(Runtime.java:545)
at org.ibex.nestedvm.Runtime.run(Runtime.java:538)
at org.ibex.nestedvm.Interpreter.main(Interpreter.java:783)
Process exited on signal 11

I wonder how hard would it be to parse the mips binary's call stack frames?

____________________________________________________________________________________Got a little couch potato?
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz

[Joe Wilson]

Pretty slick... I now know why the segfaulting source filename/line was only
displayed for me sparodically - "mips-unknown-elf-addr2line" was not always in
my PATH:

public String sourceLine(int pc) {
final String addr2line = "mips-unknown-elf-addr2line";
String line = (String) (sourceLineCache == null ? null : sourceLineCache.get(new
Integer(pc)));
if(line != null) return line;
if(image==null) return null;
try {
Process p = java.lang.Runtime.getRuntime().exec(new
String[]{addr2line,"-e",image,toHex(pc)});
line = new BufferedReader(new InputStreamReader(p.getInputStream())).readLine();
if(line == null) return null;
while(line.startsWith("../")) line = line.substring(3);
if(sourceLineCache == null) sourceLineCache = new java.util.HashMap();
sourceLineCache.put(new Integer(pc),line);
return line;
} catch(IOException e) {
return null;
}
}

Shouldn't most any GNU "addr2line" implementation work here as a fallback
if "mips-unknown-elf-addr2line" is not found?

____________________________________________________________________________________Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool.
http://autos.yahoo.com/carfinder/

[Brian Alliet]

On Sun, May 27, 2007 at 04:06:13PM -0700, Joe Wilson wrote:
> Shouldn't most any GNU "addr2line" implementation work here as a fallback
> if "mips-unknown-elf-addr2line" is not found?

Probably not. addr2line (as with the rest of the stuff in binutils)
needs to know a lot about the target binary format. The addr2line in
your path probably doesn't understand MIPS ELF binaries.

If someone were to implement a DWARF-2 parser in java we could pull the
debugging info right out of the ELF binary we already have in memory
and eliminate the dependency on addr2line. Hardly seems worth it for
this little debugging aid though.

-Brian

[Joe Wilson]

> On Sun, May 27, 2007 at 04:06:13PM -0700, Joe Wilson wrote:
> > Shouldn't most any GNU "addr2line" implementation work here as a fallback
> > if "mips-unknown-elf-addr2line" is not found?
>
> Probably not. addr2line (as with the rest of the stuff in binutils)
> needs to know a lot about the target binary format. The addr2line in
> your path probably doesn't understand MIPS ELF binaries.

addr2line appears to be ELF aware and architecture agnostic.
A stock cygwin install:

/cygdrive/c/cygwin/bin/addr2line.exe -e build/tests/Test.mips 0x11820
src/tests/Test.c:23

/cygdrive/c/cygwin/bin/addr2line.exe -e build/tests/Test.mips 0x18a20
../../../../../newlib-1.11.0/newlib/libc/stdio/printf.c:62

Not a big deal, but it might be helpful to get MIPS stack traces upon
faults when a NestedVM program is installed on a platform without the
MIPS binutils.

____________________________________________________________________________________Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz

[Brian Alliet]

On Sun, May 27, 2007 at 07:46:33PM -0700, Joe Wilson wrote:
> addr2line appears to be ELF aware and architecture agnostic.
> A stock cygwin install:

I stand corrected. It looks like most versions of binutils have a
generic elf target compiled into them (even if the target system isn't
elf). Guess they just figured that would be a handy thing to have
around (and they were right).

I'd still rather not change it. Not all systems use binutils (in
particular OS X, where I do most of my development) and I don't think
we can depend on all versions of binutils having the generic ELF
target. I support we could make it check for both, but that seems like
overkill. I'd say just hardcode addr2line in Interprter.java if you
know your systems addr2line works.

-Brian

[Joe Wilson]

> I'd still rather not change it. Not all systems use binutils (in
> particular OS X, where I do most of my development) and I don't think
> we can depend on all versions of binutils having the generic ELF
> target. I support we could make it check for both

Well, both the original poster and me had the same issue not finding
mips-unknown-elf-addr2line in our PATH. So I figure this patch is a
no-brainer. No harm if not found.