Backtracing to find the assignment of a null pointer.

From: Dileep Sankhla <dileepsankhla.ds@gmail.com>
To: kernelnewbies@kernelnewbies.org
Subject: Backtracing to find the assignment of a null pointer.
Date: Fri, 5 Jan 2024 08:46:08 +0530	[thread overview]
Message-ID: <CAHxc4btet7NE7g0osDF2VHx6WSZKcaVhrRSMP=JD_QSfzPNa=g@mail.gmail.com> (raw)

Hello everyone,

I am currently addressing a power management issue. Upon waking up
from suspend, the login screen briefly appears for a couple of
seconds, followed by the screen going blank for around 7 seconds.
Afterward, the login screen is displayed again. I've identified an
ACPI error in the journalctl entries. In the source code, I located
the line corresponding to the error message, which indicates an error
if the handler is a null pointer. This handler is one of the function
parameters, and I am interested in determining which function assigns
its value and where, how the value was set to NULL initially.
Initially, I attempted manual debugging, but after a few backtraces, I
couldn't pinpoint from where the function was called. Since I have
some experience with gdb, I decided to try it and followed both the
kernel's and gdb's documentation. To reproduce the bug, I needed a
real machine. I ran `gdbserver` by attaching it to pid 1 (I think ACPI
driver is initialized by init (pid 1)), and in another terminal tab, I
executed `gdb vmlinux`. I then set a hardware breakpoint, but when I
used `step`, I encountered an "ignoring packet error." Here is the
output:

 $ cd ~/src/linux-next
 $ gdb vmlinux
 Reading symbols from vmlinux...
 (gdb) tar remote :1234
 warning: Build ID mismatch between current exec-file
/home/dileep/src/linux-next/vmlinux
 and automatically determined exec-file /usr/lib/systemd/systemd
 exec-file-mismatch handling is currently "ask"
 Load new symbol table from "/usr/lib/systemd/systemd"? (y or n) n
 (gdb) hbreak drivers/acpi/acpica/evregion.c:131
 Hardware assisted breakpoint 1 at 0xffffffff8197e240:
drivers/acpi/acpica/evregion.c:131. (2   locations)
 (gdb) step
 warning: Remote failure reply: E01
 Ignoring packet error, continuing...
 Ignoring packet error, continuing...
 Ignoring packet error, continuing...
 Ignoring packet error, continuing...
 Ignoring packet error, continuing...
 Ignoring packet error, continuing...

And for gdbserver:

$ sudo gdbserver --attach :1234 1
Attached; pid = 1
Listening on port 1234
Remote debugging from host 127.0.0.1, port 52364
gdbserver: Couldn't write debug register: Invalid argument.
Listening on port 1234
input_interrupt, count = 1 c = 36 ('$')

Firstly, the breakpoint 1 should be set at only one location.
Secondly, I'm puzzled by the error occurring with the `step` command
in both gdb and gdbserver. Is this the correct approach for remote
kernel debugging on the same machine? If not, what would be the proper
method? I also have a MacBook Pro as a second machine. If necessary, I
can use it as a host to run gdb.

Regards,
Dileep

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