|
From: Richard Frith-M. <ri...@br...> - 2006-01-16 11:18:38
|
On 16 Jan 2006, at 10:52, Tom Hughes wrote: > In message <88F...@br...> > Richard Frith-Macdonald <ri...@br...> wrote: > >> I just tried adding '--error-limit=no' to the command line to start >> tomcat. It generates a bigger log file ... but the log file has >> stopped growing, though the valgrind/tomcat process looks like it is >> in a loop of some sort (ie a 'ps' shows it in an 'R' state). >> The log file stopped growing at 10:13, but it's now 10:40 and 'ps' >> shows the the process has now used over 28 minutes of CPU time. > > Well what does strace say it is doing? What about --trace- > syscalls=yes? I hadn't thought of that ... looks like a signal handling problem of some sort ... after adding '--trace-syscalls=yes' I get 'SYSCALL[8149,1]( 15) rt_sigreturn ( ) --> [pre-success] Success(0x0)' repeated indefinitely at the end of the log file. The log file to that point is about 900KB. > At end of the day my experience of trying to look at these problems > in the past is that the Sun JVM does truly disgusting things that are > often very hard to support in valgrind. It tends to stress just about > everything to the absolute limit especially things like threading and > signal handling. I suppose threading/signal handling are understandable given the nature of the beast. Sounds like you don't have much hope of it working though:-( > My favourite one was where it seemed to be fiddling with a memory > page (either munmap or mprotect, I can't remember which) which it > didn't seem to have allocated... It seemed to just be making > assumptions about where certain things would be in memory for some > reason. > > I assume you are using --smc-check=all or have turned the JIT compiler > off? Yes ... '/usr/local/bin/valgrind -v --trace-children=yes --smc- check=all --trace-syscalls=yes --error-limit=no --logfile=/tmp/vg' followed by the normal tomcat startup command. |