[Caml-list] Exception backtraces and stack overflows

[Alexey Rodriguez <mrchebas@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1785 bytes --]

Hi,

I am having trouble understanding exception backtraces for stack overflows.

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.

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 "compressed" the hundreds of
thousands of frames that the recursive calls generated since there is only
one entry for List.map.

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'll be
very grateful!

I can provide more details if needed, but probably someone on the list can
already help with this short description.

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.

Thanks!

Alexey

[-- Attachment #2: Type: text/html, Size: 2000 bytes --]