On Wed, Mar 09, 2022 at 08:40:50AM +0100, Jeremie Courreges-Anglas wrote:
> On Tue, Mar 08 2022, Visa Hankala wrote:
> > This patch adds kernel stack trace saving for riscv64, for the benefit
> > of dt(4) and witness(4).
>
> Nice!
>
> > The unwinder is slow because
On Tue, Mar 08 2022, Visa Hankala wrote:
> This patch adds kernel stack trace saving for riscv64, for the benefit
> of dt(4) and witness(4).
Nice!
> The unwinder is slow because of the symbol
> lookup, but this can be tweaked later.
A dumb approach that appears
This patch adds kernel stack trace saving for riscv64, for the benefit
of dt(4) and witness(4). The unwinder is slow because of the symbol
lookup, but this can be tweaked later.
The limit variable prevents the unwinder from using user-controllable
register values. The limit has to reflect the
> Date: Mon, 21 Feb 2022 17:34:14 +
> From: Visa Hankala
>
> On riscv64, ddb's stack unwinder performs poorly. The main problem is
> that the exception handlers use a frame structure (trapframe) that
> differs from the typical call frame.
>
> The following patch does several adjustments, inc
On riscv64, ddb's stack unwinder performs poorly. The main problem is
that the exception handlers use a frame structure (trapframe) that
differs from the typical call frame.
The following patch does several adjustments, including:
* Detect and handle exception frames. (Alternatively, the relevant
Sebastien Marie wrote:
>
> So calling free() with cf->cf_attach->ca_devsize should be fine.
> Diff below.
ok. didn't get to this one yet.
s missing size on free() reports it (with a backtrace to know
> the caller)
> - but report only a fixed number of calls (5), because else users will be mad
>
> so by correcting some sizes it makes others calls to free() to be visible.
>
>> free with zero size: (127)
report only a fixed number of calls (5), because else users will be mad
so by correcting some sizes it makes others calls to free() to be visible.
> free with zero size: (127)
> Starting stack trace...
> free(8013f800,7f,0,8013f800,cf43c4f465ef43f8,0) at free+
On 9.5.2019. 10:35, Sebastien Marie wrote:
> On Thu, May 09, 2019 at 10:12:49AM +0200, Hrvoje Popovski wrote:
>> Hi all,
>>
>> i update kernel from cvs few minutes ago and i'm seeing this stack trace
>> in dmesg. i'm just reporting it.
>
> The princip
On Thu, May 09, 2019 at 10:12:49AM +0200, Hrvoje Popovski wrote:
> Hi all,
>
> i update kernel from cvs few minutes ago and i'm seeing this stack trace
> in dmesg. i'm just reporting it.
The principe of the game is to look at the free() call that still use 0
as size, and f
Hi all,
i update kernel from cvs few minutes ago and i'm seeing this stack trace
in dmesg. i'm just reporting it.
free with zero size: (2)
Starting stack trace...
free(80074100,2,0,80074100,1d5a05b47900fbf4,81d287e8)
at free+0xd8
isascan(80
11 matches
Mail list logo
