Date: Sun, 27 Jul 2014 15:22:08 +0200 From: Michelle Sullivan <michelle@sorbs.net> To: David Wolfskill <david@catwhisker.org> Cc: Baptiste Daroussin <bapt@FreeBSD.org>, FreeBSD Ports ML <freebsd-ports@freebsd.org> Subject: Re: PKG 3.1.0 update - Segmentation fault: 11 Message-ID: <53D4FD00.9050204@sorbs.net> In-Reply-To: <20140727125528.GS34525@albert.catwhisker.org> References: <53D4CE4A.3040208@webrz.net> <20140727111949.GH50802@ivaldir.etoilebsd.net> <20140727123035.GR34525@albert.catwhisker.org> <53D4F2CF.4040501@sorbs.net> <20140727125528.GS34525@albert.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53D4FD00.9050204>