[Crash-utility] crash-7.3.2 very long list iteration progressively increasing memory usage
David Wysochanski
dwysocha at redhat.com
Wed Jun 27 22:18:25 UTC 2018
On Tue, 2018-06-26 at 15:34 +0100, Jeremy Harris wrote:
> On 06/26/2018 03:29 PM, David Wysochanski wrote:
> > On Tue, 2018-06-26 at 09:21 -0400, Dave Anderson wrote:
> > > Yes, by default all list entries encountered are put in the built-in
> > > hash queue, specifically for the purpose of determining whether there
> > > are duplicate entries. So if it's still running, it hasn't found any.
> > >
> > > To avoid the use of the hashing feature, try entering "set hash off"
> > > before kicking off the command. But of course if it finds any, it
> > > will loop forever.
> > >
> >
> > Ah ok yeah I forgot about the built-in list loop detection!
>
> For a storage-less method of list loop-detection: run two walkers
> down the list, advancing two versus one elements. If you ever
> match the same element location after starting, you have a loop.
I have a POC patch implementing this I'm testing. Right now I don't
have a vmcore with a list loop in it so I cannot really test it much.
Keep in mind it may be a total non-starter and I don't really know if
it works yet.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-T-option-to-list-command-to-implement-faster-loo.patch
Type: text/x-patch
Size: 3057 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20180627/08c92712/attachment.bin>
More information about the Crash-utility
mailing list