|
From: Michael R. <val...@no...> - 2005-02-09 17:28:42
|
Hi all.
First of all, I'm quite new to Valgrind, so it might well be that I'm
stumbling over something that is well known and commonly accepted.
I'm trying to hunt down some memory leaks in a program I'm writing. The
relevant lines go like this:
=== cut ===
#define PROG_DEFAULT_CFGFILE "/etc/prog.conf"
#define PROG_DEFAULT_PIDFILE "/var/run/prog.pid"
void atexit_handler(void) {
[...]
if (config.cfgfile)
free(config.cfgfile);
if (config.pidfile)
free(config.pidfile);
[...]
return;
}
int main(int argc, char *argv[]) {
config.cfgfile = strdup(PROG_DEFAULT_CFGFILE);
config.pidfile = strdup(PROG_DEFAULT_PIDFILE);
[...]
atexit(atexit_handler);
[...]
while(1) {
// main program loop
}
}
=== cut ===
The program has also a handler for SIGINT and SIGTERM, which emits a
short information and then calls "exit(0);". This way the
atexit_handler() routine is executed and the memory that has been
malloc'ed by strdup() gets freed. Well, at least that's the theory.
I run valgrind and my program with the following command:
valgrind --tool=memcheck --leak-check=yes -v ./prog --debug
The program runs fine, and when I press CTRL+C it exits as expected
after calling atexit_handler(). But still I see the following report
from valgrind:
=== cut ===
[...]
==10140== malloc/free: in use at exit: 5085 bytes in 6 blocks.
==10140== malloc/free: 1012 allocs, 1006 frees, 898940 bytes allocated.
==10140==
==10140== searching for pointers to 6 not-freed blocks.
==10140== checked 1420944 bytes.
==10140==
==10140==
==10140== 20 bytes in 1 blocks are definitely lost in loss record 2 of 6
==10140== at 0x1B904C4D: malloc (vg_replace_malloc.c:131)
==10140== by 0x1B99392F: strdup (in /lib/libc-2.3.4.so)
==10140== by 0x804A5FC: main (main.c:520)
[...]
=== cut ===
main.c:520 is the line that says:
config.pidfile = strdup(PROG_DEFAULT_PIDFILE);
The question is: why does this happen? I verified that atexit_handler()
is called when pressing CTRL+C. I also verified that
"free(config.pidfile)" is actually executed. So I'd expect that this
message should not appear at all. But it is.
Any ideas? I'm completely clueless and begin to feel like an idiot :)
Please let me know when I missed to mention relevant information.
Bye, Mike
|
|
From: Michael R. <val...@no...> - 2005-02-21 08:06:05
|
Hi all.
First of all, I'm quite new to Valgrind, so it might well be that I'm
stumbling over something that is well known and commonly accepted. If
it's just a case of RTFM, I'd be happy for any pointer to the
appropriate piece of documentation.
I'm trying to hunt down some memory leaks in a program I'm writing. The
relevant lines go like this:
=== cut ===
#define PROG_DEFAULT_CFGFILE "/etc/prog.conf"
#define PROG_DEFAULT_PIDFILE "/var/run/prog.pid"
void atexit_handler(void) {
[...]
if (config.cfgfile)
free(config.cfgfile);
if (config.pidfile)
free(config.pidfile);
[...]
return;
}
int main(int argc, char *argv[]) {
config.cfgfile = strdup(PROG_DEFAULT_CFGFILE);
config.pidfile = strdup(PROG_DEFAULT_PIDFILE);
[...]
atexit(atexit_handler);
[...]
while(1) {
// main program loop
}
}
=== cut ===
The program has also a handler for SIGINT and SIGTERM, which emits a
short information and then calls "exit(0);". This way the
atexit_handler() routine is executed and the memory that has been
malloc'ed by strdup() gets freed. Well, at least that's the theory.
I run valgrind and my program with the following command:
valgrind --tool=memcheck --leak-check=yes -v ./prog --debug
The program runs fine, and when I press CTRL+C it exits as expected
after calling atexit_handler(). But still I see the following report
from valgrind:
=== cut ===
[...]
==10140== malloc/free: in use at exit: 5085 bytes in 6 blocks.
==10140== malloc/free: 1012 allocs, 1006 frees, 898940 bytes allocated.
==10140==
==10140== searching for pointers to 6 not-freed blocks.
==10140== checked 1420944 bytes.
==10140==
==10140==
==10140== 20 bytes in 1 blocks are definitely lost in loss record 2 of 6
==10140== at 0x1B904C4D: malloc (vg_replace_malloc.c:131)
==10140== by 0x1B99392F: strdup (in /lib/libc-2.3.4.so)
==10140== by 0x804A5FC: main (main.c:520)
[...]
=== cut ===
main.c:520 is the line that says:
config.pidfile = strdup(PROG_DEFAULT_PIDFILE);
The question is: why does this happen? I verified that atexit_handler()
is called when pressing CTRL+C. I also verified that
"free(config.pidfile)" is actually executed. So I'd expect that this
message should not appear at all. But it is.
Any ideas? I'm completely clueless and begin to feel like an idiot :)
Please let me know when I missed to mention relevant information.
Bye, Mike
|
|
From: Robert W. <rj...@du...> - 2005-02-21 08:54:08
|
> =3D=3D10140=3D=3D 20 bytes in 1 blocks are definitely lost in loss record= 2 of 6 > =3D=3D10140=3D=3D at 0x1B904C4D: malloc (vg_replace_malloc.c:131) > =3D=3D10140=3D=3D by 0x1B99392F: strdup (in /lib/libc-2.3.4.so) > =3D=3D10140=3D=3D by 0x804A5FC: main (main.c:520) > [...] > =3D=3D=3D cut =3D=3D=3D Does the pointer get NULLed out at any point? --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Michael R. <val...@no...> - 2005-02-21 09:47:58
|
Hi Robert. Thanks for your reply. Robert Walsh wrote: >>==10140== 20 bytes in 1 blocks are definitely lost in loss record 2 of 6 >>==10140== at 0x1B904C4D: malloc (vg_replace_malloc.c:131) >>==10140== by 0x1B99392F: strdup (in /lib/libc-2.3.4.so) >>==10140== by 0x804A5FC: main (main.c:520) >>[...] >>=== cut === > > Does the pointer get NULLed out at any point? It didn't get NULLed out yet. I changed that now, and most of the messages about leaked memory are gone, three remained. Two of the messages can be explained (and while they can not be easily changed this doesn't hurt), and the third remaining message is the one you quote above. I ensured that this chunk of memory get's freed, and the pointer is set to zero after that as well... but the message still remains. Bye, Mike |
|
From: Robert W. <rj...@du...> - 2005-02-22 17:49:00
|
> I ensured that this chunk of memory get's freed, and the pointer is set=20 > to zero after that as well... but the message still remains. Can you file a bug? A test case to reproduce the problem would be helpful. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Michael R. <val...@no...> - 2005-02-22 21:14:31
|
Hi. Robert Walsh wrote: >>I ensured that this chunk of memory get's freed, and the pointer is set >>to zero after that as well... but the message still remains. > Can you file a bug? A test case to reproduce the problem would be > helpful. Filing this bug will have to wait for about 3 weeks (due to holiday and a move), but will be done then. Writing a test case might become a problem, since the project I'm working on consists of about 350kB non-public source. Nevertheless I'll try to get something together for this. Bye, Mike |