|
From: Selçuk C. <ce...@gm...> - 2009-12-27 08:11:52
|
Hi All, I have a bunch of C++ application which runs as daemons in Linux. Furthermore, since these daemons rely on each other, they use IPC (inter-process communication) to communicate with each other, and consume a considerable amount of memory and CPU time. These daemons are compiled with -g -O0 compiler flags, and started in right order using a shell script. These daemons seem to have buggy behaviour and "sometimes" crash. Another reason for it to crash might be corrupted input data that it processes. To find out about the real cause, I tried both Valgrind to debug it. By the way, I am quite new to Valgrind. 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. 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. What is the best debugger options to use with Valgrind to debug a Linux daemon ? Should I attach Valgrind to already running process ? or Is it ok to start the daemon with Valgrind in shell script ? Thanks. |
|
From: tom f. <tf...@al...> - 2009-12-27 17:15:41
|
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 |