kgdb and kernel space addresses

fluca1978

fluca1978

Hi all,
I was wondering if, inspecting a dump with kgdb(8) it is possible to inspect the value that was a heap address in kernel space. The kgdb does not allow me to derefence it, I suspect because the debugger is running as userland process and the address is in the kernel space, but the value should be get from the core, not real memory. Any suggestion?
 
How are you invoking kgdb? To view a core, use the command line:

[CMD=""]kgdb -c /var/crash/vmcore.<x> /boot/kernel/kernel[/CMD]

Replace <x> with the core number.

Besides, I'm in the same boat that you are. I've got a kernel thread that panics the kernel when I unload a module. The address given is not in the core dump. I have an idea as to why, but it's kinda off-topic to this thread. See this thread for my explanation.
 
Maelstorm said:
How are you invoking kgdb? To view a core, use the command line:

[CMD=""]kgdb -c /var/crash/vmcore.<x> /boot/kernel/kernel[/CMD]

Replace <x> with the core number.
Click to expand...

Yes, I'm invoking the debugger as you suggested, but nothing changed. I also tried to insert different stack frames (method wrapping) in order to see if the argument is valid in any of them, but it is not. Now, rethinking the problem, I believe the problem is that the memory address is related to the thread address space, and I suspect the dump does not include the MMU information to translate it back to a good location.
But there must be a way to find it in the dump...
 
I found something strange, just to add more doubts to my mind: two char* packed in the same structure, passed thru stack frames via a pointer, as in
Code: 
foo( struct twoStrings* uap)

having the struct defined as
Code: 
struct twoStrings{
   char* path;
   char* path1;
}

(this is a semplification of the arguments). Now while one the string is out of bound, the other is not.

Code: 
(kgdb) print 0xbfbfee16                                                                    
$6 = 3217026582                                                                            
(kgdb) print *0xbfbfee16                                                                   
Cannot access memory at address 0xbfbfee16 

(kgdb) print 0xcca15cf0                                                                    
$8 = 3433127152                                                                            
(kgdb) print *0xcca15cf0                                                                   
$9 = 511

So there is something wrong with one of the strings.
If I ask some info about the struct I got:

Code: 
(kgdb) info address uap                                                                    
Symbol "uap" is a variable with complex or multiple locations (DWARF2).
 
I think I might have lead you astray there. After I made that post, I found another way to invoke the debugger. This is in the FreeBSD Developer's Manual. Instead of using /boot/kernel/kernel as the program image, the kernel file to use is the debug kernel at /usr/obj/usr/src/sys/<x>/kernel.debug where <x> is your KERNCONF name.

What was the actual panic message? Page fault? If it was a page fault, then the address it was referring to does not exist and you will not find it in the core dump. At least that has been my experience.
 
Maelstorm said:
I think I might have lead you astray there. After I made that post, I found another way to invoke the debugger. This is in the FreeBSD Developer's Manual. Instead of using /boot/kernel/kernel as the program image, the kernel file to use is the debug kernel at /usr/obj/usr/src/sys/<x>/kernel.debug where <x> is your KERNCONF name.

What was the actual panic message? Page fault? If it was a page fault, then the address it was referring to does not exist and you will not find it in the core dump. At least that has been my experience.
Click to expand...

My fault, I was already invoking the debugger using kerne.debug and other debugging symbols, and the address is in the space, I'm sure about that since I can do a local copy of such region and it shows up while debugging the dump.
 
I've only been at this stuff for about a month now. If the address is in the dump, then there is an examine memory command... x I think. Do help x in the debugger to see how to use it. If I remember correctly, it's something like x/<count><format> address or something like that. Other than that, I don't know.
 
Maelstorm said:
I've only been at this stuff for about a month now. If the address is in the dump, then there is an examine memory command... x I think. Do help x in the debugger to see how to use it. If I remember correctly, it's something like x/<count><format> address or something like that. Other than that, I don't know.
Click to expand...

I've already tried the x option, but the error persists:

Code: 
(kgdb) x 0xbfbfee16 
0xbfbfee16:     Cannot access memory at address 0xbfbfee16

I'm sure I'm doing something wrong, that must be a way to access such location.
 
I found something that seems to me a reasonable explaination, but someone with more experience should confirm it.
The address 0xbfbfee16 is under the third gigabyte, and is not available in a kernel module dump. If I copy the string using copyinstr into the module I developed the address is placed at 0xc43e5160 and cannot be printed from the kgdb. Therefore I suspect the dump of the memory only contains the kernel data and not the user one, is this correct? Please note that I'm talking about a dump generated from within a kernel module (i.e., into a system call).
 
Yes, 0xbfbfee16 is in user space. In fact, it is in the designated stack zone for a process. The address 0xc43e5160 is in kernel space. It is also correct that a kernel memory dump will not contain any userspace data. A kernel memory dump will only contain pages that are mapped to the kernel. If you used copyinstr(9) to copy the data from user space to kernel space, then the data should be in the kernel dump file since a kernel dump file contains ALL kernel memory: code and data. The ones on my machine are about 120MB, and I'm running 2GB. Those copy functions are how data gets passed back and forth between kernel zone and user zone addresses. If the dump is created before the copy takes place, then there will be no data as it has not happened yet. Furthermore, if the memory has not been allocated, either on the stack or by using the kernel malloc, then the memory location may or may not exist.
 
You must log in or register to reply here.
Back
Top