[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM6WdxdAF5X8v_tbL1LvNDXgEPY5veL_OtQv5CrADV9qH4um-g@mail.gmail.com>
Date: Tue, 1 Nov 2022 22:50:26 +0100
From: Roland Ruckerbauer <roland.rucky@...il.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Masami Hiramatsu <mhiramat@...nel.org>,
linux-kernel@...r.kernel.org, Takashi Iwai <tiwai@...e.de>,
regressions@...ts.linux.dev,
Steven Noonan <steven.noonan@...il.com>
Subject: Re: [BUG] NULL pointer dereference probably caused by kernel/trace/ring_buffer.c
I did already check /proc/pid/syscall, and it was in syscall close().
strace is in attachment.
Seems like its closing all its files and about to exit. Maybe
something previously
corrupted some memory, and also caused the tool to exit? Could be that
the kernel crash is just the symptom of a much earlier kernel memory corruption.
Am Di., 1. Nov. 2022 um 22:38 Uhr schrieb Steven Rostedt <rostedt@...dmis.org>:
>
> On Tue, 1 Nov 2022 21:07:20 +0100
> Roland Ruckerbauer <roland.rucky@...il.com> wrote:
>
> > Meaning the rbwork pointer is not null, but also not a valid pointer.
> > Subtracting offset of the wait_index gives me address 0x178, which
> > sure seems wrong.
>
> Hmm, I wonder if the buffer got freed somehow. Not sure how that would
> happen, as you can't free the buffer if something is opened on it.
>
> >
> > I think I will try a gdb session with this kernel (but I have not done
> > this for a long time, might take me a while to get it working).
>
> If this is fully reproducible, could you run strace -f on rasdaemon to
> see what it is doing before it crashed?
>
> That could be very useful. At least I may be able to create a
> reproducer, as my rasdaemon is working fine.
>
> -- Steve
View attachment "out.txt" of type "text/plain" (30788 bytes)
Powered by blists - more mailing lists