Re: [Caml-list] native mode backtrace patch for 3.06

["Yaron Minsky" <yminsky@cs.cornell.edu>]

This looks hugely useful.  I have lots of long-running jobs that use
native code for speed, and when I get a stacktrace, it's often a lot of
work to find it, since recreating it by rerunning the bytecode can take
quite a while.

Does the patch have any performance implications?  Another thought: it
might be nice to get it to dump the failure into something analogous to a
core dump file, so that it wouldn't confuse an ordinary user, but it would
save the backtrace which could be recovered for debugging purposes.

Anyway, please do send me the patch.  Though I hope eventually this patch
or one like it ends up in the standard distribution.

y


> I've written a somewhat-hacked backtrace patch for the native mode
> compiler.  I've added a -gb option, and if you build and link with it
> on, the app prints out a list of the most recent 32 functions called
> (the code address and name) on a fatal_uncaught_exception, like this:
>
> Fatal error: exception Not_found
>         Backtrace:
>                  31: 0x0045AA28 Math2d__add_71
>                  30: 0x0045B7E4 Math2d__rotate_sc_161
> <snip>
>                   3: 0x00438D7C Debugoutput__feature_from_index_191 2:
> 0x00437CDC Debugoutput__fun_562
>                   1: 0x00438BA0
> Debugoutput__correct_feature_from_limb_175 0:
> 0x00437C2C Debugoutput__fun_554
>
> In this case the exception was from a List.find called by the #1
> function above (Debugoutput.correct_feature_from_limb), and the #0
> function is the closure passed to List.find, so it was the last function
> called before the exception was raised.
>
> I don't know if there's anybody else out there who regularly runs native
> mode and/or can't run in bytecode for performance reasons like me, but
> if so this somewhat helps make up for the lack of a debugger.  This will
> at least get you to the right function to start looking for the problem
> (and using cclib and ccopt directives to turn on debugging info in the
> underlying object files will let you debug and set breakpoints at the
> function level, assuming you're comfortable debugging assembly).  Using
> -S to generate asm lets you quickly figure out which named functions are
> referencing which anonymous closures, too.  Using this is often faster
> than binary searching with printfs, at the very least.  :)
>
> The patch should be totally portable.  I instrument functions and
> modules at the cmmgen level, so there's no platform specific code
> (unless I screwed up and made a bad assumption somewhere).  The
> instrumentation code checks for itself as the last function called, so
> deeply recursive functions won't wipe out the rest of the history
> (although two ping-ponging functions would), etc.
>
> The patch is just a record of what functions have been called recently,
> it's not a true backtrace, and it doesn't pay attention to threads or
> caught exceptions or anything else (meaning multiple threads will write
> into the same backtrace buffer, but since caml can't run multiple caml
> threads at the same time this isn't too much of a problem, you'll still
> be able to find the failing function most of the time...it would not be
> hard to fix it to have a record per thread).
>
> Send me mail if you want the patch.  I'm not on the list anymore, so
> please cc me if you reply to the list.
>
> I might also extend it to do some simple instrumented profiling, since
> gprof doesn't work on msvc.
>
> Chris
>
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives:
> http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs
> FAQ: http://caml.inria.fr/FAQ/ Beginner's list:
> http://groups.yahoo.com/group/ocaml_beginners



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners