title: How to track down a SIGFPE/Arithmetic exception
body: <p>I have a C++ application cross-compiled for Linux running on an ARM CortexA9 processor which is crashing with a SIGFPE/Arithmetic exception. Initially I thought that it's because of some optimizations introduced by the <i>-O3</i> flag of gcc but then I built it in debug mode and it still crashes. </p>
  
  <p>I debugged the application with gdb which catches the exception but unfortunately the operation triggering exception seems to also trash the stack so I cannot get any detailed information about the place in my code which causes that to happen. The only detail I could finally get was the operation triggering the exception(from the following piece of stack trace):</p>
  
  <pre><code>    3 raise()  0x402720ac   
      2 __aeabi_uldivmod()  0x400bb0b8    
      1 __divsi3()  0x400b9880
  </code></pre>
  
  <p>The <i>__aeabi_uldivmod()</i> is performing an unsigned long long division and reminder so I tried the brute force approach and searched my code for places that might use that operation but without much success as it proved to be a daunting task. Also I tried to check for potential divisions by zero but again the code base it's pretty large and checking every division operation it's a cumbersome and somewhat dumb approach. So there must be a smarter way to figure out what's happening.</p>
  
  <p>Are there any techniques to track down the causes of such exceptions when the debugger cannot do much to help?</p>
  
  <p><b>UPDATE: </b> After crunching on hex numbers, dumping memory and doing stack forensics(thanks Crashworks) I came across this gem in the ARM Compiler documentation(even though I'm not using the ARM Ltd. compiler): </p>
  
  <blockquote>
    <p>Integer division-by-zero errors can be trapped and identified by
    re-implementing the appropriate C library helper functions. The
    default behavior when division by zero occurs is that when the signal
    function is used, or
    __rt_raise() or __aeabi_idiv0() are re-implemented, __aeabi_idiv0() is
    called. Otherwise, the division function returns zero.
    __aeabi_idiv0() raises SIGFPE with an additional argument, DIVBYZERO.</p>
  </blockquote>
  
  <p>So I put a breakpoint at __aeabi_idiv0(_aeabi_ldiv0) et Voila!, I had my complete stack trace before being completely trashed. Thanks everybody for their very informative answers! </p>
  
  <p><i>Disclaimer: the "winning" answer was chosen solely and subjectively taking into account the weight of its suggestions into my debugging efforts, because more than one was informative and really helpful</i>.</p>