home ... me ... pictures ... email ... feed ... rust chronicles... twitter...

February 01, 2005

crash? please? pretty-please?

I need some variant of debugger that doesn't slow me
down so I can catch timing bugs. Or I could just write
one in my "Copious Spare Time"TM.

I find myself begging the program to just crash. SEGV?
I can find that. Kill it, take it home, cook it for dinner.

Timing on the other hand, when it gets help from latency
and packet loss, is the bitch.

music: Billy Idol: Rebel Yell

candice at February 1, 2005 11:23 PM


You should look at some of the sampling-based profilers. The Intel tools guys have one that's pretty sexy - takes a sample ever 1 msec (which, on modern processors, is only every few thousand clock cycles), and gives you a rough snapshot of the call stack based on the sampled data.

It's sampling-based, so all the normal caveats go along with that, but the approach is very lightweight and is one of the only ways to go if you're doing real intense profiling work.

Posted by: Dossy at February 2, 2005 12:37 PM

That sort of thing sounds useful.

What has been floating around in the back of my head all day is that there is probably some decent way to record run-time information and match it back up against the symbols later, other than truss which slows me down so much that it removes timing issues.

(And of course, I got clientsite this morning and my timing bug from last night? Disappeared.)

Posted by: candice at February 2, 2005 04:23 PM

In case you didn't google for "intel sampling profiler" and find out that their product is called "VTune Performance Analyzer" and since I couldn't remember the name when I commented yesterday, I did it for you. Here's a good link:



Posted by: Dossy at February 3, 2005 01:55 AM

Thanks. Will look later. I've been busy as hell between work and mardi gras.

Posted by: candice at February 3, 2005 10:45 PM

« bead-hungry zombies ... Current ... so much water »