R: Re: R: Re: 6.4-RC2 crashes after a few minutes of uptime

Rory Arms rorya+freebsd.org at TrueStep.com
Mon Nov 24 00:40:24 PST 2008


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


More information about the freebsd-stable mailing list