----- Original Message ----- > > > > Date: Tue, 16 Jun 2015 12:32:29 -0400 > > From: anderson@xxxxxxxxxx > > To: crash-utility@xxxxxxxxxx > > Subject: Re: [PATCH] Fix memory leaks in dump_mem_map when > > SPARSEMEM is enabled > > > > > > > > ----- Original Message ----- > > > > Date: Tue, 16 Jun 2015 11:14:51 -0400 > > > > From: anderson@xxxxxxxxxx > > > > To: crash-utility@xxxxxxxxxx > > > > Subject: Re: [PATCH] Fix memory leaks in dump_mem_map > > > > when > > > > SPARSEMEM is enabled > > > > > > > > > > > > Hi Oliver, > > > > > > > > Since it's a GETBUF() call, it's not really a memory leak (by design). > > > > > > Dave, > > > > > > Sorry, I'm not familiar the code. > > > > > > If the dump_mem_map get called in a thousand loop, the crash could > > > reported > > > memory allocation errors and exit the loop. > > > > Yes, except for the fact that dump_mem_map() is never called in a loop. > > But since your proposed patch does that, then yes, it would be a problem. > > > > Dave > Thanks! > > I got your point. GET_BUF just use the memory allocated by shared buffer. > > You said this is not a memory leak because crash could free all memory after crash exit. > > But if crash didn't exit, we just repeat to execute the kmem command in crash, it would cause below issue as well. > > error(FATAL, "cannot allocate any more memory!\n")); > > My "files -M" patch will make this issue more serious. The buffer is not freed "after crash exit", but rather immediately after your command is complete. To clarify, all buffers allocated by GETBUF() will be freed prior to the next "crash> " prompt, so they only exist for the period of time it takes for the single command to run. Since you are calling dump_mem_map() multiple times within your single command, your fix is required. Thanks, Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
