PKG 3.1.0 update - Segmentation fault: 11
Michelle Sullivan
michelle at sorbs.net
Sun Jul 27 13:22:12 UTC 2014
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>
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..
Regards,
Michelle
>> (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.
>
Regards,
Michelle
--
Michelle Sullivan
http://www.mhix.org/
More information about the freebsd-ports
mailing list