|
From: <bro...@co...> - 2007-01-03 00:07:53
|
Using Valgrind 3.2.1. Actually, Valgrind is not failing - it runs as it should. Rather, it is just the application that is trying to run WITHIN the Valgrind "processor" that is failing. Again, the application fails on establishing the "communication machinery", which is dependent on having certain identity checks passing succesfully. -- Bruce Rosenthal Chief Architect, TranStrophe Turning Information and Technology Into Business Opportunities 510 690 0877 510 432 7912 www.transtrophe.com -------------- Original message -------------- From: Nicholas Nethercote <nj...@cs...> > 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: <bro...@co...> - 2007-01-03 00:16:45
|
I will try using strace - should have thought of that. Oh well, rushed to get into the holiday mode after getting the system environment set-up. For what it is worth, the system is in the development stage of it's lifecycle. The version I am working with is a full quality tested release, and as I mentioned, it DOES run correctly in non-valgrindized mode. Also, the way in which the application is invoked is: 1. A "Process Manager" invokes a 2. System Manager which sources an XML control file to activate whatever applications have been configured for start-up. This System Manager will invoke the JXTA-based discovery server where all the other services the system is composed of will register capabilities and be exposed for discovery. I am thinking that because of the overhead associated with translating the instruction sets of the binary into their valgrind representations, the timing of the system is getting messed up which is causing the sytstem to fail its normal initailization routines. -- Bruce Rosenthal Chief Architect, TranStrophe Turning Information and Technology Into Business Opportunities 510 690 0877 510 432 7912 www.transtrophe.com -------------- Original message -------------- From: John Reiser <jreiser@BitWagon.com> > 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. > > -- > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: <bro...@co...> - 2007-01-03 00:24:05
|
Agreed Tom. I will use a set of strace runs to evaluate and return more meaningful output asap - sometime tomorrow when I get back to our labs. The application provides voluminous logging so I should be able to pull something. Mostly what I have observed though is that the identity piece fails immediately and then the log says the system failed to initialize communications. It could very likely be a function of how the JXTA componentry gets invoked, but as Nicolas points out, all of that should be transparent (or rather, irrelevant) to valgrind as valgrind is working at the register/stack/instruction set level. -- Bruce Rosenthal Chief Architect, TranStrophe Turning Information and Technology Into Business Opportunities 510 690 0877 510 432 7912 www.transtrophe.com -------------- Original message -------------- From: Tom Hughes <to...@co...> > In message > <010320070007.29840.459AF3D200090D80000074902206824693089B020A9C019D0D@comcast.n > et> > bro...@co... wrote: > > > Using Valgrind 3.2.1. > > > > Actually, Valgrind is not failing - it runs as it should. Rather, it is > > just the application that is trying to run WITHIN the Valgrind "processor" > > that is failing. > > > > Again, the application fails on establishing the "communication machinery", > > which is dependent on having certain identity checks passing succesfully. > > I think you need to drill deeper into exactly what is failing in your > application then - you are talking about a rather high level concept > failing as I understand things. > > Presumably if you drill down into that routine you will find some > system call that is not doing what you expect or something... That > will be a lot more helpful in trying to diagnose the problem than > what you have managed to give us so far. > > Tom > > -- > Tom Hughes (to...@co...) > http://www.compton.nu/ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Tom H. <to...@co...> - 2007-01-03 00:12:15
|
In message <010...@co...>
bro...@co... wrote:
> Using Valgrind 3.2.1.
>
> Actually, Valgrind is not failing - it runs as it should. Rather, it is
> just the application that is trying to run WITHIN the Valgrind "processor"
> that is failing.
>
> Again, the application fails on establishing the "communication machinery",
> which is dependent on having certain identity checks passing succesfully.
I think you need to drill deeper into exactly what is failing in your
application then - you are talking about a rather high level concept
failing as I understand things.
Presumably if you drill down into that routine you will find some
system call that is not doing what you expect or something... That
will be a lot more helpful in trying to diagnose the problem than
what you have managed to give us so far.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|