# kgdb and kernel space addresses



## fluca1978 (Jul 23, 2012)

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?


----------



## Maelstorm (Jul 23, 2012)

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.


----------



## fluca1978 (Jul 24, 2012)

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.



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...


----------



## fluca1978 (Jul 24, 2012)

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

```
foo( struct twoStrings* uap)
```

having the struct defined as

```
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.


```
(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:


```
(kgdb) info address uap                                                                    
Symbol "uap" is a variable with complex or multiple locations (DWARF2).
```


----------



## Maelstorm (Jul 24, 2012)

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.


----------



## fluca1978 (Jul 25, 2012)

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.



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.


----------



## Maelstorm (Jul 25, 2012)

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.


----------



## fluca1978 (Jul 26, 2012)

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.



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


```
(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.


----------



## fluca1978 (Jul 26, 2012)

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).


----------



## Maelstorm (Jul 28, 2012)

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.


----------

