<div dir="ltr">On Fri, Dec 2, 2011 at 9:28 AM, guy keren <span dir="ltr"><<a href="mailto:choo@actcom.co.il">choo@actcom.co.il</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">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).</div>
</blockquote><div><br></div><div>I think that what Nadav meant, is instead of adding </div><div><br></div><div>log_raw_data_to_file(file);</div><div><br></div><div>you can set a breakpoint there, and watch the data with gdb's x.</div>
<div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
this is the common case in storage systems - but also in other types of systems.</blockquote><div><br></div><div>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.</div>
</div></div>