[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [valgrind] [Bug 396290] [PATCH] Possible tool - allocfail
From:       <bugzilla_noreply () kde ! org>
Date:       2018-07-29 22:11:35
Message-ID: bug-396290-17878-dwZjG76Upv () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=396290

--- Comment #4 from roger.light@cedalo.com ---
Thanks for taking a look. I'm well aware that the set of tools in valgrind is a
select bunch, so I'm not expecting a merge.

Your understanding of the tool is correct. The idea of using sha3 for storing
the call stack is twofold, firstly that is what I used when I was investigating
the idea outside of valgrind, and secondly I'm not that familiar with the
valgrind api and wanted to present the idea for discussion earlier rather than
later.

Saving the whole call stack to a file would be much more desirable certainly,
it gives you much better visibility over what has gone before / caused a crash
than with the current implementation. The part that I'm missing is around
loading the call stacks in at the start - could it work in a similar fashion to
a suppression file, i.e. the file contents are loaded as the call stacks that
we should suppress the allocation failure?

I did start to look at regression tests, but didn't want to invest too much
time into them before getting a little feedback on the general idea.

-- 
You are receiving this mail because:
You are watching all bug changes.=
[prev in list] [next in list] [prev in thread] [next in thread]