Kernel Newbies Archive on lore.kernel.org
 help / color / Atom feed
* Oops stack trace missing function addresses
@ 2020-10-15 17:34 Adrian Larumbe
  2020-10-16  3:52 ` Valdis Klētnieks
  0 siblings, 1 reply; 4+ messages in thread
From: Adrian Larumbe @ 2020-10-15 17:34 UTC (permalink / raw)
  To: kernelnewbies

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Oops stack trace missing function addresses
  2020-10-15 17:34 Oops stack trace missing function addresses Adrian Larumbe
@ 2020-10-16  3:52 ` Valdis Klētnieks
  2020-10-16 11:49   ` Adrian Larumbe
  0 siblings, 1 reply; 4+ messages in thread
From: Valdis Klētnieks @ 2020-10-16  3:52 UTC (permalink / raw)
  To: Adrian Larumbe; +Cc: kernelnewbies

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Oops stack trace missing function addresses
  2020-10-16  3:52 ` Valdis Klētnieks
@ 2020-10-16 11:49   ` Adrian Larumbe
  2020-10-16 12:27     ` Alexander Kapshuk
  0 siblings, 1 reply; 4+ messages in thread
From: Adrian Larumbe @ 2020-10-16 11:49 UTC (permalink / raw)
  To: Valdis Klētnieks; +Cc: kernelnewbies

> 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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Oops stack trace missing function addresses
  2020-10-16 11:49   ` Adrian Larumbe
@ 2020-10-16 12:27     ` Alexander Kapshuk
  0 siblings, 0 replies; 4+ messages in thread
From: Alexander Kapshuk @ 2020-10-16 12:27 UTC (permalink / raw)
  To: Adrian Larumbe; +Cc: Valdis Klētnieks, kernelnewbies

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-15 17:34 Oops stack trace missing function addresses Adrian Larumbe
2020-10-16  3:52 ` Valdis Klētnieks
2020-10-16 11:49   ` Adrian Larumbe
2020-10-16 12:27     ` Alexander Kapshuk

Kernel Newbies Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kernelnewbies/0 kernelnewbies/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kernelnewbies kernelnewbies/ https://lore.kernel.org/kernelnewbies \
		kernelnewbies@kernelnewbies.org
	public-inbox-index kernelnewbies

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernelnewbies.kernelnewbies


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git