Michael Goffioul <michael.goffi...@gmail.com> writes: > GCJ is crashing at JVM initialization. At that point, no octave_java > object has been allocated yet.
My understanding is that during JVM initialization, octave_java objects
*are* allocated through static java variables initalizations. Indeed, if
I comment out this line...
vm_args.add ("-Djava.system.class.loader=org.octave.OctClassLoader");
...I get no crash during JVM initialization with GCJ.
> The only way I see octave_java could be
> at fault is that the initialization parameters are wrong or pointing
> to invalid memory. But then again, this has worked for years. If there
> was a memory corruption, I find it very unlikely that it wouldn't have
> been detected before.
I agree with you on that point, this is why I remain prudent and am only
formulating hypotheses. But sometimes memory corruption have no bad
consequences (if by chance the corrupted pointer points to an irrelevant
part of the memory) and are undetected for a long time.
Also, I would probably be more convinced that my hypothesis is wrong if
you provided the outcome of a memory checker in your environment.
Thanks,
--
Sébastien Villemot
Researcher in Economics & Debian Maintainer
http://www.dynare.org/sebastien
Phone: +33-1-40-77-84-04 - GPG Key: 4096R/381A7594
pgpsb20HzqLYO.pgp
Description: PGP signature
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
