>>>> About kgdb... >>>> I never used freebsd-update, so sorry if I'm saying >>something>>>> stupid, but could it be the case that the kernel has been >>built>>>> without debugging symbols or something like that? Does freebsd- >>>>>> update provide a kernel.debug? >>> >>> I haven't had to use a the kernel.debug file>> in the obj dir in a long >>> time. As far as I know, these days,the GENERIC>> kernel includes debug >>> symbols. And in cases when therearen't any debug>> symbols, that >>> shouldn't prevent kgdb from loading, Iwouldn't think.>> >> Hello, >> >> I had a k panic some hours ago but I thinkthat's related to a>> problem with one >> of my HDs. >> >> I've got a dumpin /var/crash, and as you were interested, I run:>> >> >> # kgdb/boot/kernel/kernel /var/crash/vmcore.6>> >> >> GNU gdb 6.1.1 >> [FreeBSD]>> >> Copyright 2004 Free Software Foundation, Inc. >> >> GDB is free >>software, covered by the GNU General Public License, and you are>> >>welcome>> to change it and/or distribute copies of it under certainconditions.>> >> Type >> "show copying" to see the conditions. >> >>There is absolutely no warranty for>> GDB. Type "show warranty" for details.>> >> This GDB was configured as "i386- >> marcel-freebsd"...(no debuggingsymbols found)...>> >> Attempt to extract a >> component of a value that isnot a structure pointer.>> >> Attempt to extract a >> component of a valuethat is not a structure pointer.>> >> Attempt to extract a >> component ofa value that is not a structure pointer.>> >> Attempt to extract a >>component of a value that is not a structure pointer.>> >> Terminated >> >>>> I had >> to pkill kgdb as it was in a loop. >> >> Running it against kernel.debug in>> /usr/obj/usr/src/sys/$KERNCONF/ worked as expected. >> I've alwaysfollowed this>> way, so I don't know if it was working with earlier releases.> >Ah, well you must not be using GENERIC then, because it does have the>debugging symbols. > >I think this is the setting in the GENERIC config thatcontrols it:> >makeoptions DEBUG=-g > >But I guess what you're doing works ifyou're using a custom kernel>that does not have that config setting. > >-rory>I'm not using GENERIC but I have makeoptions DEBUG=-g in my KERNCONF.
Rory Arms
2008-Nov-24 00:40 UTC
R: Re: R: Re: 6.4-RC2 crashes after a few minutes of uptime
On 2008-11-24, at 1:51 , Barbara wrote:>>>>> About kgdb... >>>>> I never used freebsd-update, so sorry if I'm saying >>> > something >>>>> stupid, but could it be the case that the kernel has been >>> > built >>>>> without debugging symbols or something like that? Does freebsd- >>>>> > >>> update provide a kernel.debug? >>>> >>>> I haven't had to use a the kernel. > debug file >>> in the obj dir in a long >>>> time. As far as I know, these days, > the GENERIC >>> kernel includes debug >>>> symbols. And in cases when there > aren't any debug >>> symbols, that >>>> shouldn't prevent kgdb from loading, I > wouldn't think. >>> >>> Hello, >>> >>> I had a k panic some hours ago but I think > that's related to a >>> problem with one >>> of my HDs. >>> >>> I've got a dump > in /var/crash, and as you were interested, I run: >>> >>> >>> # kgdb > /boot/kernel/kernel /var/crash/vmcore.6 >>> >>> >>> GNU gdb 6.1.1 >>> [FreeBSD] > >>> >>> Copyright 2004 Free Software Foundation, Inc. >>> >>> GDB is free >>> > software, covered by the GNU General Public License, and you are >>> >>> > welcome >>> to change it and/or distribute copies of it under certain > conditions. >>> >>> Type >>> "show copying" to see the conditions. >>> >>> > There is absolutely no warranty for >>> GDB. Type "show warranty" for details. > >>> >>> This GDB was configured as "i386- >>> marcel-freebsd"...(no debugging > symbols found)... >>> >>> Attempt to extract a >>> component of a value that is > not a structure pointer. >>> >>> Attempt to extract a >>> component of a value > that is not a structure pointer. >>> >>> Attempt to extract a >>> component of > a value that is not a structure pointer. >>> >>> Attempt to extract a >>> > component of a value that is not a structure pointer. >>> >>> Terminated >>> >>> > >>> I had >>> to pkill kgdb as it was in a loop. >>> >>> Running it against kernel. > debug in >>> /usr/obj/usr/src/sys/$KERNCONF/ worked as expected. >>> I've always > followed this >>> way, so I don't know if it was working with earlier releases. > >> >> Ah, well you must not be using GENERIC then, because it does have the > >> debugging symbols. >> >> I think this is the setting in the GENERIC config that > controls it: >> >> makeoptions DEBUG=-g >> >> But I guess what you're doing works if > you're using a custom kernel >> that does not have that config setting. >> >> - > rory >> > > I'm not using GENERIC but I have > makeoptions DEBUG=-g > in my KERNCONF.Barbara, Ah, so you had the exact same results I got, when using /book/kernel/ kernel. So, that answers that question then, apparently I do need to build a kernel.debug to get a backtrace on 6.4. So, it looks like maybe things are different in 6 than I had remembered. I haven't looked at the 6.4-RC2 notebook to see what the kernel directory has, but on my 7.0 server at least, I've noticed that kgdb(1) does work with /book/kernel/kernel, and I think it might have to do with putting the symbols in a separate, kernel.symbols file. So, I assume that this doesn't exist on 6. However I did notice that if I remove that file, and run kgdb again (on 7.0) I also get that structure pointer error that you get, it doesn't lock up.. and I can still get a backtrace, but the output is more terse.. in that it shows function names, but without corresponding source file names and line numbers. So, the addition of the symbols file it seems, adds some some more debugging information than what the kernel provides by itself. So, maybe that makeoptions directive does different things on each version. Thank you for your feedback with this, much appreciated. Now, to see if I can build a kernel.debug on that machine, can get a backtrace -- though it sure sounds like a problem with ata(4). - rory