Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Good Profiler



kevin kommented:
| Anthony Gabrielson <agabriel at home.tzo.org> writes:
|
| > 	I have an app I wrote for class that is fairly large and due on
| > Thursday...  Unfortunately I'm getting signal 11 after the app is running
| > for a second or so and I need to track the memory exception down quicker
| > than I am.  Does any know of a good profiler for linux that can do this?
|
| Use a debugger like gdb.  From what you describe, you don't want a
| profiler.

And, of course, if the error is  in  your  own  code,  compiling  and
linking  with  the  -p  -g  options  will  pinpoint the line where it
happened.

Of course, this assumes you're using one of (g)cc's languages. I note
that the language wasn't stated. If it's perl or python, for example,
the answer would be totally different.  You don't want to know  where
it bombed in the interpreter, after all.  Well, maybe you do, if it's
a bug in the interpreter.  But that ain't gonna be fixed by Thursday;
you'll  have  to  recode the section of code so as to not trigger the
bug if you're to have it working by then.

With a compiled program, though, turning on profiling with -p -g  can
give you detailed information about the crash and gdb can do a lot to
tell you what the program was up to.





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org