On 02/11/2012 07:24 PM, julien2412 wrote:
On master branch (not on 3.5 branch), each time I start a module Calc,
Writer or Impress (I didn't test on others), when I begin to type something,
it seems to freeze for some seconds (about 10 secs) then everything seems
ok.
So I runned valgrind by using this :
valgrind --tool=memcheck --num-callers=50 --trace-children=yes ./soffice.bin
2>&1 | tee /tmp/valgrind.log
If you suspect the cause for the delay to be unnecessary large amounts
of code being executed, you should run valgrind with --tool=callgrind.
With this, I can't start LO at all because there are too much errors. By
taking a look, 98% of them are like this :
==4110== Invalid write of size 4
==4110== at 0x2E7BE641: ???
==4110== by 0x2E7AF437: ???
==4110== by 0x2DA518CE: JavaCalls::call_helper(JavaValue*, methodHandle*,
JavaCallArguments*, Thread*) (in
/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
[...]
JVMs are notorious for producing false positives from valgrind. I once
improved that somewhat, by forcing the JVM into interpreted mode when
run under valgrind (see "forceInterpreted" in
jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx), but even the
non-JITed code still produces noise (which I was able to silence at
least on a Fedora 16 with trunk valgrind via a
{
java-1
Memcheck:Addr4
...
obj:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so
}
{
java-2
Memcheck:Addr8
fun:_wordcopy_fwd_dest_aligned
# (in /lib64/libc-2.14.so)
fun:__GI_memmove
# (in /lib64/libc-2.14.so)
fun:realpath@@GLIBC_2.3
# (in /lib64/libc-2.14.so)
obj:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libjava.so
fun:Java_java_io_UnixFileSystem_canonicalize0
# (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libjava.so)
}
{
java-3
Memcheck:Cond
obj:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so
}
valgrind suppressions file).
I noticed these lines too :
700 #ifdef MACOSX
701 vm_args.version= JNI_VERSION_1_4; // issue 88987
702 #else
703 vm_args.version= JNI_VERSION_1_2;
704 #endif
If we support jdk 1.4 min, we could use JNI version 1.4 according to this
http://docs.oracle.com/javase/1.4.2/docs/guide/jni/jni-14.html, no ? (or
perhaps it would need lots of changes to use it except for MacOS where it's
already used)
Yes, we could probably simplify the code by always using
JNI_VERSION_1_4. But it should probably not make a difference (note
that the example at
<http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html#wp16334>
still uses 1_2, and only states that it must be at least 1_2, but not
that setting it to a higher value has any special effect), and who knows
what would break with all those varied JVM implementations out there.
Stephan
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
