Hi again,<div><br></div><div>A colleague suggested doing the following experiment: call List.map on a large list and throw an exception from deep down in the call chain.</div><div><br></div><div>Now the backtrace I get contains 1022 entries for map, an entry for the raise site and some other entry. This matches the 1024 limit of BACKTRACE_BUFFER_SIZE. Since the limit has been reached, the backtrace is useless to diagnose the stack overflow. This matches my understanding of caml_stash_backtrace: all stack frames are inspected and reported as long as there is space in the trace buffer.</div>
<div><br></div><div>So it seems there is something funny happening when a stack overflow is detected in the SIGSEGV handler:  there are only 3 trace entries whereas the stack contains over a hundred thousand frames. Is this intended behavior?</div>
<div><br></div><div>If it is of any help I am including the test program. I am using Ocaml 3.12.0 on a x86-64 platform.</div><div><br></div><div>Cheers,</div><div><br></div><div>Alexey</div><div><br><div class="gmail_quote">
On Mon, Jul 16, 2012 at 3:51 PM, Alexey Rodriguez <span dir="ltr">&lt;<a href="mailto:mrchebas@gmail.com" target="_blank">mrchebas@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<div><br></div><div>I am having trouble understanding exception backtraces for stack overflows.</div><div><br></div><div>Sometimes the backtrace only contains entries for the function that filled the stack with frames (you would see many backtrace entries pointing to List.map if you were trying to map a very long list). Such traces are useless to fix the stack overflow since you cannot use them to find the code path that leads to List.map.</div>

<div><br></div><div>In other situations, the backtrace contains the full path from the Ocaml entry point to the recursive functions that is blowing up the stack. In these situations the backtrace appears to have &quot;compressed&quot; the hundreds of thousands of frames that the recursive calls generated since there is only one entry for List.map.</div>

<div><br></div><div>Is there documentation that explains when you get one backtrace or the other? I tried to understand the source code of caml_stash_backtrace and there it seems that all the stack frames are captured (if the backtrace buffer size allows). Casual inspection with gdb shows that caml_stash_backtrace does not get the full stack at the moment of the fault. Maybe the signal handler is skipping over the hundreds of thousands of frames somehow? If someone can elucidate this mystery for me I&#39;ll be very grateful!</div>

<div><br></div><div>I can provide more details if needed, but probably someone on the list can already help with this short description.</div><div><br></div><div>Oh, one more question on backtraces. I see that when tracing is enabled, caml_stash_backtrace is called whenever an exception is thrown. This might be expensive as Not_found is raised by many functions in the standard library. Is there a high overhead in leaving tracing enabled? This is useful in production systems as very often it is not possible to have the original inputs to trigger the bug in a debug build.</div>

<div><br></div><div>Thanks!</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Alexey</div>
</font></span></blockquote></div><br></div>