David Wolfskill wrote:
> On Sun, Jul 27, 2014 at 02:38:39PM +0200, Michelle Sullivan wrote:
>> ...
>> By any chance is there a core file around releated to this, and if so
>> was the binary that faulted unstripped?
> In each of the 3 cases, I find a
> /usr/ports/ports-mgmt/pkg/pkg-static.core file
> g1-252(9.3-S)[4] sudo file pkg-static.core
> Password:
> pkg-static.core: ELF 32-bit LSB core file Intel 80386, version 1 (FreeBSD), 
> FreeBSD-style, from '-static'
> g1-252(9.3-S)[5] 

Doesn't appear stripped..
>> I'd be interested in seeing the backtrace...
> Well, given it was a segmentation fault, it's not clear to me that
> I'd be able to find much of value -- I'm way out of practice using
> gdb, and by the nature of a segmentation fault (or what caused it,
> anyway), something is pretty confused by the time the fault is
> discovered.
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>


set args <what ever is approrpiate>

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..



>> (I'm not using 1.3 or even NG on any of my production
>> systems at the moment because I personally don't trust it yet (I have 57
>> complex systems and if they screw up I end up rebuilding the OS from
>> scratch) so I'd be happy to take a look at any cores an unstripped
>> binaries to see if I can work out why people see this occasionally... 
>> Sounds like you have 3 identical systems which 2 worked no problems the
>> third faulted .. this is obviously not good and needs to be fixed, so
>> will give another pair of eyes at the problem.
> Err... no....  I have 5 system in total; 2 haven't failed because
> I haven't tried to update them yet: if they fail, I don't have
> access to email (or much of anything else); more critially, neither
> does my spouse -- and I value domestic tranquility.
Ahh - so all 3 failed, the other 2 have not been tried?

> Of the 3 failures, 2 were on i386; one on amd64.
> They are all running stable/9 @r269090 (and the 2 that I haven't
> upgraded yet would normally be upgraded to that point before I start
> messing with ports on them).
> I'll be happy to provide any information about this that I can.



Michelle Sullivan

freebsd-ports@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Reply via email to