On 27/07/2014 14:22, Michelle Sullivan wrote: > Unless the fault smashed the stack often you can find what the > problem/cause was. If the stack is smashed you're screwed. > > gdb <path to binary> <path to core> > > Commands immediately useful: > > backtrace full (alias: bt full) > frame <number> for which you want to examine > if you get a line number/code, 'l' (el) will give the 5 lines eitherside > If threaded select each thread before the frame to see what was > happening in each thread. > > If I remember correctly - it's been several years since I last used gdb ;-) > > If you want to catch a smashed stack problem run the binary in gdb: > > gdb <path to command> > > Then: > > set args <what ever is approrpiate> > run > > When it faults most of the time you'll get the stack just prior to the > smashing - though I have had some really bad ones when even gdb cored out.. > > If the process forks out, you will need to use follow-fork..
Actually pkg(8) pretty much always forks itself -- run it with the '-d'
flag to prevent that.
However, this particular crash is something we've received plenty of
reports about. I believe bapt has a fix just about ready, but he's AFK
for a little while. If you'ld like to help with testing and stuff,
might I suggest joining #pkgng on freenode IRC?
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
JID: matt...@infracaninophile.co.uk
signature.asc
Description: OpenPGP digital signature
