|
From: Tom S. <to...@pl...> - 2004-06-21 19:25:23
|
In a previous thread (valgrinding GCJ Java code), I explained the
problems trying to use valgrind on a program that was structured like this:
C main() -> GCJ runtime
It was suggested in that thread (by Jeroen N. Witmond), that I try to
run valgrind directly on the JVM. I have found that it doesn't work for
me. Although the JVM and Java app run, valgrind stops reporting once
the JVM is created.
Here is a simple test case.
/* bar.c
* Compile with:
* SDK=/usr/lib/j2se/1.4
* gcc -I$SDK/include -I$SDK/include/linux -fPIC bar.c -o bar
* gcc -I$SDK/include -I$SDK/include/linux -fPIC -c bar.c
* gcc -shared -nostartfiles -fPIC bar.o -o libbar.so
* $SDK/bin/javac Foo.java
* Run C:
* ./bar
* Run Java:
* $SDK/bin/java -Djava.library.path=. Foo
* Valgrind C:
* valgrind --leak-check=yes ./bar
* Valgrind Java:
* valgrind --leak-check=yes $SDK/bin/java -Djava.library.path=. Foo
*/
#include <stdlib.h>
#include <jni.h>
char bar(void) {
char * arr;
arr = (char *) malloc(10);
return(arr[20]); /* invalid read and memory leak */
}
int main(int argc, char * argv[]) {
char ch;
ch = bar();
printf("C returning %i\n", ch);
return(ch);
}
JNIEXPORT jint JNICALL Java_Foo_foo(
JNIEnv * env,
jclass cls
) {
return(bar());
}
/* Foo.java */
public class Foo {
public static native int foo();
public static void main(String args[]) {
System.out.println("Java starting");
System.loadLibrary("bar");
int ch = foo();
System.out.println("Java exiting " + ch);
}
}
And here is the output that I get when I run valgrind on the Sun JVM:
$ valgrind --leak-check=yes $SDK/bin/java -Djava.library.path=. Foo
==9554== Memcheck, a memory error detector for x86-linux.
==9554== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward.
==9554== Using valgrind-2.1.1, a program supervision framework for
x86-linux.
==9554== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward.
==9554== For more details, rerun with: -v
==9554==
Java starting
Java exiting 101
$
Note that there is no ERROR SUMMARY or LEAK SUMMARY, nor does valgrind
detect the invalid read.
I am not expecting someone to fix my problem, I am just presenting to
the list my results and test cases. Of course if someone has an answer,
I am listening...
--
Tom Schutter (mailto:to...@pl...)
Platte River Associates, Inc. (http://www.platte.com)
|
|
From: Tom S. <to...@pl...> - 2004-06-21 21:49:42
|
Tom Schutter wrote: > It was suggested in that thread (by Jeroen N. Witmond), that I try to > run valgrind directly on the JVM. I have found that it doesn't work for > me. Although the JVM and Java app run, valgrind stops reporting once > the JVM is created. I have just run the test case using the SableVM, and got nearly identical results. $ valgrind java-sablevm Foo ==13463== Memcheck, a memory error detector for x86-linux. ==13463== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. ==13463== Using valgrind-2.1.1, a program supervision framework for x86-linux. ==13463== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. ==13463== For more details, rerun with: -v ==13463== ==13463== Syscall param sigaction(act) contains uninitialised or unaddressable byte(s) ==13463== at 0x3C0A5025: __libc_sigaction (in /lib/tls/libc-2.3.2.so) ==13463== Address 0x4FFFE640 is on thread 1's stack Java starting Java exiting 33 $ In this case valgrind reports a problem with __libc_sigaction(), but again fails to report code problems or the usual summary. I forgot to put version info in my original post: j2sdk1.4 1.4.1.99rc1-2 Blackdown Java(TM) 2 SDK, Standard Edition sablevm 1.1.0-5 Free implementation of Java Virtual Machine libsablevm1-de 1.1.0-5 Free implementation of JVM secon edition -d valgrind 2.1.1-3 A memory debugger for x86-linux -- Tom Schutter (mailto:to...@pl...) Platte River Associates, Inc. (http://www.platte.com) |
|
From: Nicholas N. <nj...@ca...> - 2004-06-22 08:57:27
|
On Mon, 21 Jun 2004, Tom Schutter wrote: > And here is the output that I get when I run valgrind on the Sun JVM: > $ valgrind --leak-check=yes $SDK/bin/java -Djava.library.path=. Foo > ==9554== Memcheck, a memory error detector for x86-linux. > ==9554== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. > ==9554== Using valgrind-2.1.1, a program supervision framework for > x86-linux. > ==9554== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. > ==9554== For more details, rerun with: -v > ==9554== > Java starting > Java exiting 101 > $ > > Note that there is no ERROR SUMMARY or LEAK SUMMARY, nor does valgrind > detect the invalid read. Does --trace-children=yes help? N |
|
From: Tom S. <to...@pl...> - 2004-06-22 15:47:33
|
Nicholas Nethercote wrote: > On Mon, 21 Jun 2004, Tom Schutter wrote: > > >>And here is the output that I get when I run valgrind on the Sun JVM: >>$ valgrind --leak-check=yes $SDK/bin/java -Djava.library.path=. Foo >>==9554== Memcheck, a memory error detector for x86-linux. >>==9554== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. >>==9554== Using valgrind-2.1.1, a program supervision framework for >>x86-linux. >>==9554== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. >>==9554== For more details, rerun with: -v >>==9554== >>Java starting >>Java exiting 101 >>$ >> >>Note that there is no ERROR SUMMARY or LEAK SUMMARY, nor does valgrind >>detect the invalid read. > > > Does --trace-children=yes help? $ valgrind --leak-check=yes --trace-children=yes $SDK/bin/java -Djava.library.path=. Foo ==1687== Memcheck, a memory error detector for x86-linux. ==1687== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. ==1687== Using valgrind-2.1.1, a program supervision framework for x86-linux. ==1687== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. ==1687== For more details, rerun with: -v ==1687== ==1687== Memcheck, a memory error detector for x86-linux. ==1687== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. ==1687== Using valgrind-2.1.1, a program supervision framework for x86-linux. ==1687== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. ==1687== For more details, rerun with: -v ==1687== Repeats same 6 lines forever until Ctrl-C is pressed. ==1687== ==1687== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 1) ==1687== malloc/free: in use at exit: 4466 bytes in 3 blocks. ==1687== malloc/free: 3 allocs, 0 frees, 4466 bytes allocated. ==1687== For counts of detected errors, rerun with: -v ==1687== searching for pointers to 3 not-freed blocks. ==1687== checked 1671012 bytes. ==1687== ==1687== LEAK SUMMARY: ==1687== definitely lost: 0 bytes in 0 blocks. ==1687== possibly lost: 0 bytes in 0 blocks. ==1687== still reachable: 4466 bytes in 3 blocks. ==1687== suppressed: 0 bytes in 0 blocks. ==1687== Reachable blocks (those to which a pointer was found) are not shown. ==1687== To see them, rerun with: --show-reachable=yes -- Tom Schutter (mailto:to...@pl...) Platte River Associates, Inc. (http://www.platte.com) |
|
From: Jeroen N. W. <jn...@xs...> - 2004-06-22 10:33:38
|
> On Mon, 21 Jun 2004, Tom Schutter wrote: > >> And here is the output that I get when I run valgrind on the Sun JVM: >> $ valgrind --leak-check=yes $SDK/bin/java -Djava.library.path=. Foo >> ==9554== Memcheck, a memory error detector for x86-linux. >> ==9554== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. >> ==9554== Using valgrind-2.1.1, a program supervision framework for >> x86-linux. >> ==9554== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. >> ==9554== For more details, rerun with: -v >> ==9554== >> Java starting >> Java exiting 101 >> $ >> >> Note that there is no ERROR SUMMARY or LEAK SUMMARY, nor does valgrind >> detect the invalid read. > > Does --trace-children=yes help? FWIW, on my system it does help in producing more messages, among which: ==16314== Warning: set address range perms: large range 134217728, a 0, v 0 ==16314== Warning: set address range perms: large range 134217728, a 1, v 1 ==16314== Warning: set address range perms: large range 134283264, a 0, v 0 ==16314== warning: Valgrind's pthread_attr_destroy does nothing ==16314== your program may misbehave as a result ==16314== warning: Valgrind's pthread_getattr_np is incomplete ==16314== your program may misbehave as a result ==16314== warning: Valgrind's pthread_attr_getstackaddr is incomplete ==16314== (it always sets stackaddr to zero) ==16314== your program may misbehave as a result ==16314== warning: Valgrind's pthread_getattr_np is incomplete ==16314== your program may misbehave as a result ==16314== warning: Valgrind's pthread_attr_getstackaddr is incomplete ==16314== (it always sets stackaddr to zero) ==16314== your program may misbehave as a result followed by many messages like: ==16314== Invalid write of size 4 ==16314== at 0x45B3BE4A: ??? ==16314== by 0x45B36DDA: ??? ==16314== by 0x45B34103: ??? ==16314== by 0x418661E7: JavaCalls::call_helper(JavaValue *, methodHandle *, JavaCallArguments *, Thread *) (in /home/local/j2sdk1.4.1/jre/lib/i386/client/libjvm.so) ==16314== Address 0xBFFFAD08 is not stack'd, malloc'd or free'd ==16314== ==16314== Invalid write of size 4 ==16314== at 0x45B3BE4A: ??? ==16314== by 0x45B36DDA: ??? ==16314== by 0x45B36DDA: ??? ==16314== by 0x45B34103: ??? ==16314== Address 0xBFFFACE0 is not stack'd, malloc'd or free'd and finally: Fatal: Stack size too small. Use 'java -Xss' to increase default stack size. followed by the error summary etc. I have not tried this -Xss option because at the time of the fault, all RAM (330M) and all swapspace (240M) on my system was used. Jeroen. |
|
From: Tom H. <th...@cy...> - 2004-06-22 11:17:25
|
In message <434...@we...>
Jeroen N. Witmond <jn...@xs...> wrote:
> and finally:
>
> Fatal: Stack size too small. Use 'java -Xss' to increase default stack size.
>
> followed by the error summary etc.
>
> I have not tried this -Xss option because at the time of the fault, all
> RAM (330M) and all swapspace (240M) on my system was used.
You would all save yourselves a lot of trouble if you went and read
the commentary on bug 69508 at:
http://bugs.kde.org/show_bug.cgi?id=69508
There is a patch there that extends the support for various features
in libpthread and at one point it was enough to get the JVM going
again but later versions of the JVM seemed to start failing again.
As I recall the last time I looked at it I decided that the JVM was
doing such horrible things that it stood next to no chance of being
made to work.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|