Hi Oliver, Since it's a GETBUF() call, it's not really a memory leak (by design). But it's certainly unnecessary for CONFIG_SPARSEMEM kernels. Queued for crash-7.1.2:
https://github.com/crash-utility/crash/commit/005eb9e502056a09196f6507162648c796e36f95 Thanks, Dave ----- Original Message ----- > Signed-off-by: Yong Yang <[email protected]> > --- > memory.c | 7 +++---- > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/memory.c b/memory.c > index 32427ea..765732b 100644 > --- a/memory.c > +++ b/memory.c > @@ -5734,10 +5734,6 @@ dump_mem_map(struct meminfo *mi) > long buffersize; > char *outputbuffer; > int bufferindex; > - > - buffersize = 1024 * 1024; > - outputbuffer = GETBUF(buffersize + 512); > - > char style1[100]; > char style2[100]; > char style3[100]; > @@ -5748,6 +5744,9 @@ dump_mem_map(struct meminfo *mi) > return; > } > > + buffersize = 1024 * 1024; > + outputbuffer = GETBUF(buffersize + 512); > + > sprintf((char *)&style1, "%%lx%s%%%dllx%s%%%dlx%s%%8lx %%2d%s", > space(MINSPACE), > (int)MAX(PADDR_PRLEN, strlen("PHYSICAL")), > -- > 1.9.1 > > -- > Crash-utility mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/crash-utility > -- Crash-utility mailing list [email protected] https://www.redhat.com/mailman/listinfo/crash-utility
