On Tue, Jun 19, 2012 at 11:03 PM, Sébastien Villemot <
sebastien.ville...@ens.fr> wrote:
> Michael Goffioul <michael.goffi...@gmail.com> writes:
>
> > On Tue, Jun 19, 2012 at 9:50 PM, Jordi Gutiérrez Hermoso <
> jord...@octave.org> wrote:
>
> > >> Sigh, this is from an optimised build. It's half useless. I guess
> I'll
> > >> have to produce my own stack trace and valgrind output in a debug
> > >> build.
> > >
> > >> I don't see any Octave source code in the valgrind output except
> at a
> > >> location that points to a line in a source file that doesn't seem
> to
> > >> exist.
> > >
> > > Which file?
> >
> > The valgrind output is pointing to __java__.cc:523, but that's a
> > comment line in the Java package.
> >
> > It's crashing at the create_jvm call, that is JNI_CreateJavaJVM. To be
> > honest, I don't know why it's crashing, but I'd suspect some
> > incompatibility with GCJ. That code has worked for years with
> > Sun/Oracle java.
>
> I used to think that the java package was incompatibile with GCJ, but
> now I have changed my mind. I experience the same valgrind errors with
> both OpenJDK 6/7 and GCJ. My current hypothesis is that the java package
> creates invalid pointers in some Java objects, and whether and where
> this leads to a crash depends on the JVM implementation; this would
> explain why I was not experiencing crashes with OpenJDK 6, while I do
> now with OpenJDK 7.
>
> Of course I understand very well that as long as you cannot reproduce
> it, you can't fix it.
>
> Maybe you've already tested that, but are you able to replicate the
> valgrind messages?
>
My feeling is more that those valgrind messages are just a red herring and
not directly related to the crash. These messages are all about
uninitialized memory, not about accessing invalid memory or trying to free
invalid memory segment. And all these messages relates to the garbage
collector (memory manager), so I'm not too concerned about them.
GCJ is crashing at JVM initialization. At that point, no octave_java object
has been allocated yet. 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.
>From what you say, OpenJDK is crashing in a much more involved way. This is
quite different form the GCJ case.
Michael.
------------------------------------------------------------------------------
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
