|
From: Tom S. <to...@pl...> - 2004-06-18 15:32:59
|
Andrew Haley wrote: > Tom Schutter writes: > > Boehm, Hans wrote: > > > I don't know what the specific issue is here. > > > > The specific issue is that control never returns from JvCreateJavaVM() > > or JNI_CreateJavaVM() when the app is run under valgrind. > > I don't know much about Valgrind. However, my understanding is that > Valgrind is supposed to emulate the host CPU, albeit more slowly. Yes, that is correct. > So, > if the host CPU returns, so should Valgrind. That makes your problem > a Valgrind bug, doesn't it? Maybe, maybe not. As far as I understand, GCJ is doing non-standard things with stacks. A valgrind internals expert could probably explain better why it is possibly a GCJ problem. -- Tom Schutter (mailto:to...@pl...) Platte River Associates, Inc. (http://www.platte.com) |
|
From: Andrew H. <ap...@re...> - 2004-06-18 15:41:23
|
Tom Schutter writes: > Andrew Haley wrote: > > Tom Schutter writes: > > > Boehm, Hans wrote: > > > > I don't know what the specific issue is here. > > > > > > The specific issue is that control never returns from JvCreateJavaVM() > > > or JNI_CreateJavaVM() when the app is run under valgrind. > > > > I don't know much about Valgrind. However, my understanding is that > > Valgrind is supposed to emulate the host CPU, albeit more slowly. > > Yes, that is correct. > > > So, > > if the host CPU returns, so should Valgrind. That makes your problem > > a Valgrind bug, doesn't it? > > Maybe, maybe not. As far as I understand, GCJ is doing non-standard > things with stacks. I can't think of anything in particular. Scanning the stack, maybe? But there's nothing weird or illegal about that. Andrew. |