|
From: Karl C. <ka...@cs...> - 2014-07-09 11:48:15
|
On 07/08/2014 02:04 PM, Philippe Waroquiers wrote: > On Tue, 2014-07-08 at 03:49 -0400, Karl Cronburg wrote: >> Any idea as to what's going on, or how I might debug the problem further? >> Any Valgrind flags or options I might be missing? The RVM runs fine >> on its' own, as well as in Nulgrind (and cachegrind and callgrind): > > From what I can see, the above happens when Valgrind is not able to > track properly the stack used by a thread. > The 'switching stacks' messages very probably indicate that the jikes > rvm does something special with stack. > If that is the case, then usually the problem can be solved by adding > client requests in the application code (the various VALGRIND_STACK_* > client requests in valgrind.h). > > > This might also happen due to the use of sigaltstack. > It is unclear to me how to properly inform Valgrind of such alternate > stack. > > In both case, basically, the problem is that valgrind believes that the > stack goes from the current stack pointer value till the "last known > stack base". When changing stack; this can include non addressable > segments. The stack unwind code assumes however that everything is > accessible between the current sp and the stack base. You're right, this was the problem. I verified that the stack base pointer was way to large (right next to the SIGSEGV address). I've also found that everything runs fine when I add the "--keep-stacktraces=none" flag, which is acceptable for now since I'm more interested in the Java stack traces inside the RVM anyways. Thanks! -Karl- |