9:38 a.m.
Signed-off-by: Yong Yang <yangoliver(a)gmail.com>
---
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
10:14 a.m.
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/005eb9e502056a09196f6507162...
Thanks,
Dave
----- Original Message -----
Signed-off-by: Yong Yang <yangoliver(a)gmail.com>
---
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
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
10:59 a.m.
Date: Tue, 16 Jun 2015 11:14:51 -0400
From: anderson(a)redhat.com
To: crash-utility(a)redhat.com
Subject: Re: [Crash-utility] [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.After I fixed with this patch, the issue got
disappeared.
I'm not sure you know the reason, if not, I can show you the error messages.
But it's certainly unnecessary for CONFIG_SPARSEMEM kernels.
Queued
for crash-7.1.2:
https://github.com/crash-utility/crash/commit/005eb9e502056a09196f6507162...
Thanks,
Dave
----- Original Message -----
> Signed-off-by: Yong Yang <yangoliver(a)gmail.com>
> ---
> 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
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
11:32 a.m.
----- Original Message -----
> Date: Tue, 16 Jun 2015 11:14:51 -0400
> From: anderson(a)redhat.com
> To: crash-utility(a)redhat.com
> Subject: Re: [Crash-utility] [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
After I fixed with this patch, the issue got disappeared.
I'm not sure you know the reason, if not, I can show you the error messages.
> But it's certainly unnecessary for CONFIG_SPARSEMEM kernels. Queued
> for crash-7.1.2:
>
>
https://github.com/crash-utility/crash/commit/005eb9e502056a09196f6507162...
>
> Thanks,
> Dave
>
>
> ----- Original Message -----
> > Signed-off-by: Yong Yang <yangoliver(a)gmail.com>
> > ---
> > 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
> > Crash-utility(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/crash-utility
> >
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
6:24 p.m.
Date: Tue, 16 Jun 2015 12:32:29 -0400
From: anderson(a)redhat.com
To: crash-utility(a)redhat.com
Subject: Re: [Crash-utility] [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(a)redhat.com
> > To: crash-utility(a)redhat.com
> > Subject: Re: [Crash-utility] [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.
8:19 a.m.
----- Original Message -----
> Date: Tue, 16 Jun 2015 12:32:29 -0400
> From: anderson(a)redhat.com
> To: crash-utility(a)redhat.com
> Subject: Re: [Crash-utility] [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(a)redhat.com
> > > To: crash-utility(a)redhat.com
> > > Subject: Re: [Crash-utility] [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
11:05 a.m.
Date: Wed, 17 Jun 2015 09:19:50 -0400
From: anderson(a)redhat.com
To: crash-utility(a)redhat.com
Subject: Re: [Crash-utility] [PATCH] Fix memory leaks in dump_mem_map when SPARSEMEM is
enabled
----- Original Message -----
>
>
> > Date: Tue, 16 Jun 2015 12:32:29 -0400
> > From: anderson(a)redhat.com
> > To: crash-utility(a)redhat.com
> > Subject: Re: [Crash-utility] [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(a)redhat.com
> > > > To: crash-utility(a)redhat.com
> > > > Subject: Re: [Crash-utility] [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.
Got it. Thanks for your explanations. :)
3450
days inactive
3451
days old
devel@lists.crash-utility.osci.io
6 comments
2 participants
participants (2)
-
Dave Anderson -
yangoliver