Oops stack trace missing function addresses

Oops stack trace missing function addresses

[Adrian Larumbe]

Hi everyone,

I wrote a small kernel module where I trigger a page fault by writing
to an invalid memory address. This causes an Oops that prints the
associated Stack Trace, but contrary to what the kernel documentation
claims, I get no VA next to each function in the Call Trace:

Call Trace:
  do_one_initcall+0xfc/0x290
  ? cache_alloc_debugcheck_after+0x38/0x270
  ? rcu_read_lock_sched_held+0x77/0xa0
  ? kmem_cache_alloc_trace+0x2b6/0x330
  do_init_module+0x4b/0x1b6
  load_module+0x2140/0x24c0
  ? find_held_lock+0x2d/0xa0
  sys_init_module+0xdd/0x100
  do_int80_syscall_32+0x73/0x170
  entry_INT80_32+0xcf/0xcf

This looks very much unlike what I see in https://www.kernel.org/doc/html/v4.11/admin-guide/bug-hunting.html

I was wondering maybe the reason is that I didn't compile the kernel with the right debug options, but
a quick glance at the .config file reveals they all seem to be there:

CONFIG_DEBUG_INFO=y
CONFIG_STACKTRACE=y
CONFIG_DEBUG_BUGVERBOSE=y

Cheers,
Adrian



_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Oops stack trace missing function addresses

[Valdis Klētnieks]

[-- Attachment #1.1: Type: text/plain, Size: 635 bytes --]

On Thu, 15 Oct 2020 18:34:08 +0100, Adrian Larumbe said:

> claims, I get no VA next to each function in the Call Trace:
>
> Call Trace:
>   do_one_initcall+0xfc/0x290
>   ? cache_alloc_debugcheck_after+0x38/0x270
>   ? rcu_read_lock_sched_held+0x77/0xa0
>   ? kmem_cache_alloc_trace+0x2b6/0x330
>   do_init_module+0x4b/0x1b6
>   load_module+0x2140/0x24c0

OK, I'll bite.  You *are* getting the function name and offset, what additional
knowledge do you get from knowing the VA?

What architecture is this on?  Stack unwinding is architecture-dependent, so
it may just be the unwinder for that arch doesn't output the virtual address.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Oops stack trace missing function addresses

[Adrian Larumbe]

> OK, I'll bite.  You *are* getting the function name and offset, what additional
> knowledge do you get from knowing the VA?

I was hoping to use the VA to calculate the C source line where the
fault happens, by substracting the function's VA from the module load
address as revealed by cat /proc/modules, adding the offset within the
function and then passing the offset to addr2line.

I've just realised I might as well load the module object file into gdb
and do 'info line *(func+offset)'.

But how would I do this just with addr2line ?

> What architecture is this on?  Stack unwinding is architecture-dependent, so
> it may just be the unwinder for that arch doesn't output the virtual address.

It's a QEMU VM, 'uname -m' claims it's i686.



_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Oops stack trace missing function addresses

[Alexander Kapshuk]

On Fri, Oct 16, 2020 at 2:49 PM Adrian Larumbe <fromago@gmail.com> wrote:
>
> > OK, I'll bite.  You *are* getting the function name and offset, what additional
> > knowledge do you get from knowing the VA?
>
> I was hoping to use the VA to calculate the C source line where the
> fault happens, by substracting the function's VA from the module load
> address as revealed by cat /proc/modules, adding the offset within the
> function and then passing the offset to addr2line.
>
> I've just realised I might as well load the module object file into gdb
> and do 'info line *(func+offset)'.
>
> But how would I do this just with addr2line ?

scripts/faddr2line path/to/module.ko symbol+0xsym_offset/0xsym_size
would give you the C source line referenced by the offset.

>
> > What architecture is this on?  Stack unwinding is architecture-dependent, so
> > it may just be the unwinder for that arch doesn't output the virtual address.
>
> It's a QEMU VM, 'uname -m' claims it's i686.
>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies