You did not CC valgrind-users in your reply. I am forwarding the message back to them.
Please keep the list involved. -tom ------- Forwarded Message In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Date: Sun, 27 Dec 2009 20:44:36 +0200 Message-ID: <[email protected]> Subject: in C++ From: Selçuk Cevher <[email protected]> To: tom fogal <[email protected]> - --0015174483dc3dafca047bba2e3a Content-Type: text/plain; charset=ISO-8859-1 To be able to run as a daemon, my application runs the fork() command for once. This is the common practice to create a daemon. I added --trace-children=yes to the debugger options. However, Memcheck still did not identify any bad operation in terms of invalid write/read or uninitialized values. But, when I run it natively, it crashes. On Sun, Dec 27, 2009 at 7:16 PM, tom fogal <[email protected]> wrote: > writes: > > Hi All, > > > > I have a bunch of C++ application which runs as daemons in Linux. > > > > Another reason for it to crash might be corrupted input data that it > > processes. > > > > I used --leak-check=yes and --log-file=foo.txt options with Valgrind. > > > > However, Valgrind did not report any invalid write/read or > > uninitialized variable errors which may have caused the crash. > > It might be that your daemon is a `true' daemon, in that it does the > double fork trick. In that case, you want to make sure you use the > command line option "--trace-children=yes". > > Less like is that you might be hitting the issue that Valgrind cannot > detect all possible errors. See: > > http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.machine > > I believe there is a semi-recent paper from a group out of UMass > Amherst which also goes into detail about the types of errors dynamic > analysis tools can find, and valgrind is one of the tools they > evaluate. > > > FAQ on Valgrind's official website says that this is the nature of > > Valgrind that you can not change such that it can not replicate the > > native execution environment. > > I do not think this is an issue with the change in execution > environment. That's normally more of an issue with e.g. timed sections > of code or threading. > > > What is the best debugger options to use with Valgrind to debug a > > Linux daemon ? > > Other than the potential lack of --trace-children, your options seem > fine. > > > Should I attach Valgrind to already running process ? or Is it ok to > > start the daemon with Valgrind in shell script ? > > It is not possible to attach valgrind to a process after execution has > started, due to the nature of how it works. It'll be obvious when > you read the above link: what would the `V' bits get set to when you > attach, for example? > > -tom
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
