title: Memory corrupted crash analysis
body: <p>This question is to get ideas. So basically we have run into a particular crash, where the backtrace is meaningless above some frame. This is from an ARM based binary. We were unable to reproduce the issue yet, which hardens the analysis. Some observations first:</p>
  
  <ul>
  <li>Nearly all the required libraries' unstripped shared libraries are available so the backtrace should be ok normally</li>
  <li>However, the backtrace points on frame 3 to a memory address, which is clearly not in the code segment</li>
  <li>That problematic memory address is also visible in some argument parameters</li>
  <li>Register info shows unaligned address on R3 register. Disassemble shows that stmia ASM operation on it, which was the root cause - it caused sigbus.</li>
  </ul>
  
  <p>All in all, this is because of a corrupted memory, stack, etc. I have only limited information right now. I want to trace back at least where this call came, but because of the corruption, I am now not really able to find it.</p>
  
  <p>Do you have any ideas, how to proceed which such problems? Any tools, which can help me to analyze the assembly flow and data and registers in a better environment, maybe seeing the stack, etc in a more intuitive way? Much thanks in advance!</p>
  
  <p>EDIT: To be a bit more precise: how would you try to find out what was above frame 2? Is it possible in some scenarios to decode it back, even though the stack was somehow corrupted? Or finding out what corrupted it?</p>
  
  <p>EDIT2: i think i will debug that function and I saw a particular log line before  the crash. I will place a breakpoint and check where the calls are coming, albeit it is a very generic méthod, plus the initialization functions' orders are really fuzzy. Have no other clue. Do you have some "intuitive reading ASM level data from core file" tool idea?</p>