|
From: <bro...@co...> - 2007-01-02 22:16:07
|
I am attempting to evaluate a complex system using callgrind and cachegrind. When I invoke the system it fails to initialize as it does on normal operational mode. My call is as follows, as an example: root@myhost>valgrind --tool=callgrind --dump-instr=yes --trace-jumps=yes the.path.to.the.app Now the system is quite complex and essentially creates and instantiates multiple objects including a JXTA-based discovery server object, identity checking objects, read and write connection listeners and acceptors, policy dissemination objects etc... The main problem is that the identity object's methods to authenticate the calling subject always is failing so all the initial communications set-up fails because nothing happens unless the identitycheck is evaluated as succesful. I cannot give more details then these abstractions at this time. And I am not really sure what guidance I need, but I suppose a starting point is whether there is a way to see what is happening in terms of valgrind translations of the operational instruction sets. Or if there is a way to attach to the main processes PIDs after a normal, non-valgrindized start-up (I think this is impossibel if I understand the way valgrind works as a processor simulator). -- Bruce Rosenthal Chief Architect, TranStrophe Turning Information and Technology Into Business Opportunities 510 690 0877 510 432 7912 www.transtrophe.com |
|
From: Nicholas N. <nj...@cs...> - 2007-01-02 22:33:18
|
On Tue, 2 Jan 2007 bro...@co... wrote: > I am attempting to evaluate a complex system using callgrind and > cachegrind. When I invoke the system it fails to initialize as it does on > normal operational mode. My call is as follows, as an example: > > root@myhost>valgrind --tool=callgrind --dump-instr=yes --trace-jumps=yes the.path.to.the.app > > Now the system is quite complex and essentially creates and instantiates > multiple objects including a JXTA-based discovery server object, identity > checking objects, read and write connection listeners and acceptors, > policy dissemination objects etc... > > The main problem is that the identity object's methods to authenticate the > calling subject always is failing so all the initial communications set-up > fails because nothing happens unless the identitycheck is evaluated as > succesful. All this is irrelevant from Valgrind's point of view. Valgrind mostly works at the binary level, eg. instructions, system calls, registers, memory locations, with a few library-level details such as heap blocks allocated via malloc. > I cannot give more details then these abstractions at this time. You haven't said how Valgrind fails, what the failing output looks like, which version you're running, what platform you're using, etc. If you cannot divulge these things then I doubt anyone will be able to help you. > And I am not really sure what guidance I need, but I suppose a starting > point is whether there is a way to see what is happening in terms of > valgrind translations of the operational instruction sets. > > Or if there is a way to attach to the main processes PIDs after a normal, > non-valgrindized start-up (I think this is impossibel if I understand the > way valgrind works as a processor simulator). Correct, Valgrind cannot do this. There's a similar tool called Pin, from Intel, which can do this. Nick |
|
From: John R.
|
bro...@co... wrote: > I am attempting to evaluate a complex system using callgrind and cachegrind. When I invoke the system it fails to initialize as it does on normal operational mode. ... > And I am not really sure what guidance I need, but I suppose a starting point is whether there is a way to see what is happening in terms of valgrind translations of the operational instruction sets. strace still works to reveal system calls. For instance: strace -f -o strace.out valgrind --tool=callgrind ... which often produces voluminous output. To limit the trace to system calls involving filenames, which might be an interesting observation point between full strace and nothing: strace -f -o strace.out -e trace=file valgrind --tool=callgrind ... Other options can tailor the trace to include read/write/seek/socket etc. strace also can be attached dynamically; see the manual page. Beyond strace there is systemtap (experimental) on recent versions of Fedora Core. Another suggestion is to prune the instances of valgrind until the problem goes away. Omit applying valgrind at the outermost level, and/or at the innermost level (replace the innermost level by a shell script that invokes the original innermost executable without calling valgrind), etc. -- |
|
From: Julian S. <js...@ac...> - 2007-01-02 23:22:30
|
> Another suggestion is to prune the instances of valgrind until the problem > goes away. Omit applying valgrind at the outermost level, and/or at the > innermost level (replace the innermost level by a shell script that invokes > the original innermost executable without calling valgrind), etc. Also worth trying --tool=none just in case it's something specific just in case it's something specific to cachegrind/callgrind. I doubt it is, but still .. J |