I have fought the smtp auth beastie and finally won. (postfix->sasl->mysql for dbmail.)
The "debugger" I cooked up works for acquiring stack traces out of stuff with memgrep, and parsing/looking up -after- the snapshot has been taken works so far. Two more main things - setting up a dumb script to do snapshots on intervals, and a quick program to find process's children so that those can be debugged quickly.
This inspired by a giant pile of spaghetti code which gdb and other more normal tracing tools run too slowly to be useful.
I cooked this up for one of my clients just now, and I wanted to put it in a public place. Feel free to comment over on my regular weblog.
To get gdb to start a program do either: $ gdb binary OR $ gdb <stuff> (gdb) file binary
You'll need to start the program now, with any arguments if it takes them: (gdb) run [arguments]
To run gdb on a core file gives you roughly the same stuff as getting the program to crash while the debugger is running. Run: $ gdb binary corefile
To use gdb to attach to a running process, find the pid of the process you want to debug. Do either: $ gdb binary pid OR $ gdb binary <stuff> (gdb) attach pid
This stops your process, in order to continue it immediately do: (gdb) cont
Otherwise you may want to look at a stack trace of where we are right now, and maybe some of the values of variables.
Stack Traces: (gdb) where OR (gdb) bt
This numbers the stack frame as well, and by default you are at the deepest level.
Printing Variables: (gdb) print myvariable
This works on values within the current scope - by default they are in the deepest frame on the stack, but you can change frame by: (gdb) frame 10
Breakpoints and Stepping:
You can at this point continue the program to get where you want it to go, or you can set up some breakpoints to make the program stop at a specific line. (You can also make the program stop with ctrl-c) (gdb) break foo.c:400 (gdb) cont
You can also step line by line from your current location. 'next' executes the next line, and 'step' executes the next line but steps into the next line if it is a function call. Both take numeric arguments so you can say 'next 10' and it will try to execute the next ten lines. (gdb) next 2 (gdb) step
When a program crashes in the debugger, it will stop in gdb (generally - given we are not set up to operate within a subprocess - which you can look up in the online docs) and you can do any of these commands except executing further.
Anything else and specifics on these commands you can look up by doing 'help' at the gdb prompt (gdb) help
Public service announcement:
Do not ever work for RIT.
I finished up some contract work that got arranged after the first time they decided they didn't want to pay me, and am still having problems getting paychecks.
Technical stuff? what's that?
Been ungodly busy since I got laid off and had the world further turned on its end by a car accident on my way home of the last day of work. Working on offloading my pdp11's, they're sold and need to be shipped, a pile of mac stuff, some old crappy monitors are going to need some new homes too.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!