Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Actually you have quite a lot of possibilities. Either with recompilation of source code or without.</p> <h2>With recompilation.</h2> <ul> <li>Additional <a href="http://en.wikipedia.org/wiki/Computer_data_logging" rel="nofollow noreferrer">logging</a>. Either into program's logs or using system logging (eg. OutputDebugString or Events Log on Windows). Also use following steps: <ul> <li>Always include timestamp at least up to seconds resolution.</li> <li>Consider adding thread-id in case of multithreaded apps.</li> <li>Add some nice output of your structures</li> <li>Do not print out enums with just %d. Use some <code>ToString()</code> or create some <code>EnumToString()</code> function (whatever suits your language)</li> <li>... and beware: logging <strong>changes</strong> timings so in case of heavily multithreading you problems might disappear.</li> <li>More details on this <a href="https://stackoverflow.com/questions/1592457/how-you-can-debug-a-program-without-a-debugger/1592463#1592463">here</a>.</li> </ul></li> <li>Introduce more asserts</li> <li>Unit tests</li> <li><em>"Audio-visual"</em> monitoring: if something happens do one of <ul> <li>use buzzer </li> <li>play system sound </li> <li>flash some LED by enabling hardware GPIO line (only in embedded scenarios) </li> </ul></li> </ul> <h2>Without recompilation</h2> <ul> <li>If your application uses network of any kind: <a href="http://en.wikipedia.org/wiki/Packet_analyzer" rel="nofollow noreferrer">Packet Sniffer</a> or I will just choose for you: <a href="http://www.wireshark.org/" rel="nofollow noreferrer">Wireshark</a></li> <li>If you use database: monitor queries send to database and database itself.</li> <li>Use virtual machines to test exactly the same OS/hardware setup as your system is running on.</li> <li>Use some kind of system calls monitor. This includes <ul> <li>On Unix box <a href="http://en.wikipedia.org/wiki/Strace" rel="nofollow noreferrer">strace</a> or <a href="http://en.wikipedia.org/wiki/DTrace" rel="nofollow noreferrer">dtrace</a></li> <li>On Windows tools from former <a href="http://technet.microsoft.com/en-us/sysinternals/default.aspx" rel="nofollow noreferrer">Sysinternals</a> tools like <a href="http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx" rel="nofollow noreferrer">http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx</a>, <a href="http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx" rel="nofollow noreferrer">ProcessExplorer</a> and alike</li> <li>In case of Windows GUI stuff: check out <a href="http://msdn.microsoft.com/en-us/library/aa264396%28VS.60%29.aspx" rel="nofollow noreferrer">Spy++</a> or for WPF <a href="http://blois.us/Snoop/" rel="nofollow noreferrer">Snoop</a> (although second I didn't use)</li> <li>Consider using some profiling tools for your platform. It will give you overview on thing happening in your app.</li> </ul></li> <li><strong>[Real hardcore]</strong> Hardware monitoring: use oscilloscope (aka O-Scope) to monitor signals on hardware lines</li> <li>Source code debugging: you sit down with your source code and just pretend with piece of paper and pencil that you are computer. Its so called code analysis or "on-my-eyes" debugging</li> <li>Source control debugging. Compare diffs of your code from time when "it" works and now. Bug might be somewhere there. </li> </ul> <p>And some general tips in the end:</p> <ul> <li>Do not forget about <em>Text to Columns</em> and <em>Pivot Table</em> in Excel. Together with some text tools (<code>awk</code>, <code>grep</code> or <code>perl</code>) give you incredible analysis pack. If you have more than 32K records consider using Access as data source.</li> <li>Basics of <a href="http://en.wikipedia.org/wiki/Data_warehouse" rel="nofollow noreferrer">Data Warehousing</a> might help. With simple cube you may analyse tons of temporal data in just few minutes.</li> <li>Dumping your application is worth mentioning. Either as a result of crash or just on regular basis</li> <li><strong>Always</strong> generate you debug symbols (even for <a href="https://stackoverflow.com/questions/420343">release builds</a>).</li> <li>Almost last but not least: most mayor platforms has some sort of command line debugger always built in (even Windows!). With some tricks like conditional debugging and break-print-continue you can get pretty good result with obscure bugs</li> <li>And really last but not least: use your brain and <strong>question everything</strong>.</li> </ul> <p>In general debugging is like science: you do not create it you discover it. Quite often its like looking for a murderer in a criminal case. So buy yourself <a href="http://images.google.com/images?client=safari&amp;rls=en&amp;q=sherlock+holmes+hat&amp;oe=UTF-8&amp;um=1&amp;ie=UTF-8&amp;ei=2EjdSsr_F8P54AbugOkK&amp;sa=X&amp;oi=image_result_group&amp;ct=title&amp;resnum=1&amp;ved=0CBYQsAQwAA" rel="nofollow noreferrer">a hat</a> and never give up.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload