On Fri, Dec 2, 2011 at 9:28 AM, guy keren <c...@actcom.co.il> wrote: > you can use a debugger only for the basic code. you cannot use a debugger > when you're dealing with multiple threads that access the same shared data > and could have race conditions. in those cases you need to run a test, find > that the eventual data is incorrect, and track back using logs and friends, > to find the culprit(s). >
I think that what Nadav meant, is instead of adding log_raw_data_to_file(file); you can set a breakpoint there, and watch the data with gdb's x. Like you I find the printf-debugging approach more appealing, but it might be that I'm just stuck in the past, and reluctant to try new tools. > > this is the common case in storage systems - but also in other types of > systems. Other type I ran into, is when passing binary data from process A to process B using pipes, it's extremely quick to test the actual data with ./proc | hexdump -C, then by redirecting the output to a file, or tapping the network/pipe.
_______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
