Thread (12 messages) flat view 12 messages, 2 authors, 2021-06-16

Re: Suggestions on how to debug kernel crashes where printk and gdb both does not work

From: Dongliang Mu <hidden>
Date: 2021-06-14 14:20:40
Also in: lkml

On Mon, Jun 14, 2021 at 9:34 PM Pavel Skripkin [off-list ref] wrote:
On Mon, 14 Jun 2021 21:22:43 +0800
Dongliang Mu [off-list ref] wrote:
quoted
Dear kernel developers,

I was trying to debug the crash - memory leak in hwsim_add_one [1]
recently. However, I encountered a disgusting issue: my breakpoint and
printk/pr_alert in the functions that will be surely executed do not
work. The stack trace is in the following. I wrote this email to ask
for some suggestions on how to debug such cases?

Thanks very much. Looking forward to your reply.
Hi, Dongliang!

This bug is not similar to others on the dashboard. I spent some time
debugging it a week ago. The main problem here, that memory
allocation happens in the boot time:
quoted
[<ffffffff84359255>] kernel_init+0xc/0x1a7 init/main.c:1447
Oh, nice catch. No wonder why my debugging does not work. :(
and reproducer simply tries to
free this data. You can use ftrace to look at it. Smth like this:

$ echo 'hwsim_*' > $TRACE_DIR/set_ftrace_filter
Thanks for your suggestion.

Do you have any conclusions about this case? If you have found out the
root cause and start writing patches, I will turn my focus to other
cases.

BTW, I only found another possible memory leak after some manual code
review [1]. However, it is not the root cause for this crash.

[1] https://lkml.org/lkml/2021/6/10/1297
would work.


With regards,
Pavel Skripkin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help