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?



Dr Matthew J Seaman MA, D.Phil.

PGP: http://www.infracaninophile.co.uk/pgpkey
JID: matt...@infracaninophile.co.uk

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to