* [Caml-list] native mode backtrace patch for 3.06
@ 2003-09-27 17:51 Chris Hecker
2003-09-27 23:04 ` malc
` (3 more replies)
0 siblings, 4 replies; 6+ messages in thread
From: Chris Hecker @ 2003-09-27 17:51 UTC (permalink / raw)
To: caml-list
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] native mode backtrace patch for 3.06
2003-09-27 17:51 [Caml-list] native mode backtrace patch for 3.06 Chris Hecker
@ 2003-09-27 23:04 ` malc
2003-09-28 11:52 ` Yaron Minsky
` (2 subsequent siblings)
3 siblings, 0 replies; 6+ messages in thread
From: malc @ 2003-09-27 23:04 UTC (permalink / raw)
To: Chris Hecker; +Cc: caml-list
On Sat, 27 Sep 2003, Chris Hecker wrote:
>
> 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
http://groups.google.com/groups?q=fourth+shared+patch&hl=en&lr=&ie=UTF-8&selm=fa.gbof7hv.fmmo03%40ifi.uio.no&rnum=1
Cross platform support for this was done, nearly one year ago..
(Link is dead, but im not)
--
mailto:malc@pulsesoft.com
-------------------
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] native mode backtrace patch for 3.06
2003-09-27 17:51 [Caml-list] native mode backtrace patch for 3.06 Chris Hecker
2003-09-27 23:04 ` malc
@ 2003-09-28 11:52 ` Yaron Minsky
[not found] ` <64571.209.54.74.251.1064749973.squirrel@minsky-primus.home ip.net>
2003-09-28 19:18 ` Byron Hale
3 siblings, 0 replies; 6+ messages in thread
From: Yaron Minsky @ 2003-09-28 11:52 UTC (permalink / raw)
To: checker; +Cc: caml-list
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] native mode backtrace patch for 3.06
[not found] ` <64571.209.54.74.251.1064749973.squirrel@minsky-primus.home ip.net>
@ 2003-09-28 16:39 ` Chris Hecker
2003-09-28 22:10 ` malc
0 siblings, 1 reply; 6+ messages in thread
From: Chris Hecker @ 2003-09-28 16:39 UTC (permalink / raw)
To: Yaron Minsky; +Cc: caml-list
At 07:52 9/28/2003 -0400, Yaron Minsky wrote:
>Does the patch have any performance implications?
The instrumentation code it adds (to every function, even small ones, although that could be changed relatively easily by adding some kind of function-length metric, maybe what the inliner uses) will take some time, but in the brief test I did it didn't make much difference in my game, which was a pleasant surprise (even when it was added to tiny things like a 2D vector addition that's used everywhere). Maybe inlining happens before cmmgen or something, I don't know.
>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.
That would be easy, since the printout is in C and just fprintfs to stderr. I should also add a caml interface to it in Sys or something, that just returns the data, so you can put a try ... with _ -> Sys.get_debug_native_backtrace () around your whole program (or in an atexit) and do whatever you want with it.
>Anyway, please do send me the patch. Though I hope eventually this patch
>or one like it ends up in the standard distribution.
A couple others have asked for it, so I'll clean it up and post it on my website. I'll send mail to the list when I do that.
At 03:04 9/28/2003 +0400, malc wrote:
>http://groups.google.com/groups?q=fourth+shared+patch&hl=en&lr=&ie=UTF-8&selm=fa.gbof7hv.fmmo03%40ifi.uio.no&rnum=1
>Cross platform support for this was done, nearly one year ago..
>(Link is dead, but im not)
Ah, I probably should have searched, but it sounds like yours is not available anymore, and it's also part of something bigger? Did you instrument in cmmgen.ml as well, or do it differently?
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] native mode backtrace patch for 3.06
2003-09-27 17:51 [Caml-list] native mode backtrace patch for 3.06 Chris Hecker
` (2 preceding siblings ...)
[not found] ` <64571.209.54.74.251.1064749973.squirrel@minsky-primus.home ip.net>
@ 2003-09-28 19:18 ` Byron Hale
3 siblings, 0 replies; 6+ messages in thread
From: Byron Hale @ 2003-09-28 19:18 UTC (permalink / raw)
To: caml-list
Hi Chris,
No wonder there was no SFBA meeting this month. I would like to have this
patch.
I looked at the d6 Web site. Interesting! I had concluded that OpenGL was
my 3D API of choice.
I used to run a computer game developers' SIG for the Software Forum, once
the Software Entrepreneurs' Forum, now the Software Development Forum. I
was doing some work for SF Canyon Co, when it folded.
Best Regards,
Byron Hale
byron.hale@einfo.com
At 10:51 AM 9/27/2003 -0700, Chris Hecker wrote:
>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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] native mode backtrace patch for 3.06
2003-09-28 16:39 ` Chris Hecker
@ 2003-09-28 22:10 ` malc
0 siblings, 0 replies; 6+ messages in thread
From: malc @ 2003-09-28 22:10 UTC (permalink / raw)
To: Chris Hecker; +Cc: Yaron Minsky, caml-list
On Sun, 28 Sep 2003, Chris Hecker wrote:
> At 03:04 9/28/2003 +0400, malc wrote:
> >http://groups.google.com/groups?q=fourth+shared+patch&hl=en&lr=&ie=UTF-8&selm=fa.gbof7hv.fmmo03%40ifi.uio.no&rnum=1
> >Cross platform support for this was done, nearly one year ago..
> >(Link is dead, but im not)
>
> Ah, I probably should have searched, but it sounds like yours is not available anymore, and it's also part of something bigger? Did you instrument in cmmgen.ml as well, or do it differently?
http://www.boblycat.org/~malc/scaml/
And yes, cmmgen and some c files were touched
--
mailto:malc@pulsesoft.com
-------------------
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-09-28 22:07 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-09-27 17:51 [Caml-list] native mode backtrace patch for 3.06 Chris Hecker
2003-09-27 23:04 ` malc
2003-09-28 11:52 ` Yaron Minsky
[not found] ` <64571.209.54.74.251.1064749973.squirrel@minsky-primus.home ip.net>
2003-09-28 16:39 ` Chris Hecker
2003-09-28 22:10 ` malc
2003-09-28 19:18 ` Byron Hale
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).