Re: SableVM on ARM fails to run HelloWorld

The class loader _is_ looking in the current directory (as I said, this 
was obvious from strace'ing).

The difference between putting the file in the sablevm-classpath and 
some other working dir is indeed that in the latter case, the class 
loading is initiated by java.lang.ClassLoader.loadClass rather than the 
bootstrap class loader directly.

By debugging I noticed that in 
sablevm-classpath-1.12/java/net/URLClassLoader.java, the FileResource 
that is created at the beginning of URLClassLoader.findClass returns a 
resource.getLength() == 0. Which I think is not what to expect (this 
length == 0 results in the failure of _svmh_parse_class_file (in 
sablevm-1.12/src/libsablevm/class_file_parser.c).

Adding System.out.println statements, I found that File.length() does 
not produce the same result when called upon multiple times.
I ended up trying to verify VMFile.length(), but printf() statements in 
sablevm-classpath-1.12/native/jni/java-io/java_io_VMFile.c resulted in 
segfaults...

- Chris

Etienne Gagnon wrote:
> Hi Chris,
> 
> OK, so this confirms that the problem is class-library related.  The
> internal bootstrap class loader seems to be working fine.  This can
> greatly simplify your search for the bug.
> 
> For one thing, it seems that the System class loader is either:
> 1- not working at all, or
> 2- not looking in the current directory.
> 
> I suspect that "1-" is the case, here.  By putting the file in
> <install-dir>/share/sablevm-classpath, the class was probably loaded by
> the bootstrap class loader (i.e. sablevm's internal class loader).
> 
> You should start your investigation at
> ClassLoader.defaultGetSystemClassLoader() in sablevm-classpath.
> 
> As this happens out of the bootstrap cycle, you can probably add
> "System.out.println()" statements to track down execution without
> hitting chicken-egg bootstrap problems.  In last resort, SableVM
> provides java.lang package-specific VirualMachine.println() statements
> which require no bootstrap support.
> 
> Have fun!
> 
> Etienne
> 
> 
> 
> Chris Develder wrote:
> 
>>I found that copying the HelloWorld.class file to
>><install-dir>/share/sablevm-classpath (alongside the jars) makes
>>'sablevm HelloWorld' work.
>>
>>This lead me to believe that the current working directory was not
>>checked when looking for HelloWorld.class. Yet, without the .class file
>>in <install-dir>/share/sablevm-classpath, I did find (using strace) that
>>the file in the pwd was looked for and opened... But then the
>>java.lang.ClassFormatError occurs.
>>
>>Apparently files in the classpath and pwd are not treated in the same way?
>>
>>
>>>Can you check what happens when mmap() is used to read the class file
>>>insrc/libsablevm/class_loader.c (or src/libsablevm/zip_file_reader.c).
>>
>>As for mmap: I added printfs before all mmap calls, but they were never
>>reached.  I did notice failing open() calls using strace, where attempts
>>are made to acces files that are actually in the jars in the classpath.
>>(Making/installing sablevm-classpath uncompressed makes the open() calls
>>work)  I guess that it is normal that in case of sablevm-classpath with
>>compressed classfiles _svmf_bootcl_internal_load_ondisk_class_file is
>>called and fails (for the .class files are in the jar)?
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> SableVM-user mailing list
> [email protected]
> http://sablevm.org/lists/control/listinfo/sablevm-user