This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/6940] New: Leak in tzset_internal function when TZ environment variable doesn't exist ?
- From: "homer242 at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 3 Oct 2008 14:03:21 -0000
- Subject: [Bug libc/6940] New: Leak in tzset_internal function when TZ environment variable doesn't exist ?
- Reply-to: sourceware-bugzilla at sourceware dot org
I have wrote this little program to show you the problem:
{{{
#include <stdlib.h>
#include <stdio.h>
#include <syslog.h>
static void __attribute__((constructor)) __init(void)
{
dmalloc_debug_setup("log-stats,log-non-free,check-fence,log=/tmp/test-leak-syslog.%p");
}
int main(int argc, char **argv)
{
unsigned long mark;
char c;
/* get the current dmalloc position */
while(1)
{
mark = dmalloc_mark();
syslog(LOG_DEBUG, "Hello World");
/*
* log unfreed pointers that have been added to
* the heap since mark
*/
dmalloc_log_changed(mark,
1 /* log unfreed pointers */,
0 /* do not log freed pointers */,
1 /* log each pnt otherwise summary */);
sleep(2);
}
return 0;
}
}}}
with no TZ variable defined in the environment, dmalloc output give me this:
{{{
1223040961: 5: Dmalloc version '5.5.2' from 'http://dmalloc.com/'
1223040961: 5: flags = 0x403, logfile '/tmp/test-leak-syslog.1261'
1223040961: 5: interval = 0, addr = 0, seen # = 0, limit = 0
1223040961: 5: starting time = 1223040961
1223040961: 5: process pid = 1261
1223040961: 5: WARNING: tried to free(0) from 'ra=0x555571e26c'
1223040961: 23: Dumping Not-Freed Pointers Changed Since Start:
1223040961: 23: not freed: '0x1201f5f28|s1' (15 bytes) from 'ra=0x55557088dc'
1223040961: 23: not freed: '0x1201f5f88|s1' (20 bytes) from 'ra=0x555571cb90'
1223040961: 23: not freed: '0x1201f5fa8|s1' (20 bytes) from 'ra=0x555571cb90'
1223040961: 23: not freed: '0x1201f5fc8|s1' (20 bytes) from 'ra=0x555571cb90'
1223040961: 23: not freed: '0x1201fc808|s1' (1872 bytes) from 'ra=0x555571e344'
1223040961: 23: not freed: '0x1201fdf48|s1' (21 bytes) from 'ra=0x555571cb90'
1223040961: 23: not freed: '0x1201fdf88|s1' (21 bytes) from 'ra=0x555571cb90'
1223040961: 23: not freed: '0x1201fdfc8|s1' (21 bytes) from 'ra=0x555571cb90'
1223040961: 23: total-size count source
1223040961: 23: 1872 1 ra=0x555571e344
1223040961: 23: 123 6 ra=0x555571cb90
1223040961: 23: 15 1 ra=0x55557088dc
1223040961: 23: 2010 8 Total of 3
1223040963: 35: Dumping Not-Freed Pointers Changed Since Mark 23:
1223040963: 35: not freed: '0x1201f5ec8|s1' (15 bytes) from 'ra=0x55557088dc'
1223040963: 35: total-size count source
1223040963: 35: 15 1 ra=0x55557088dc
1223040963: 35: 15 1 Total of 1
1223040965: 47: Dumping Not-Freed Pointers Changed Since Mark 35:
1223040965: 47: not freed: '0x1201f5fe8|s3' (15 bytes) from 'ra=0x55557088dc'
1223040965: 47: total-size count source
1223040965: 47: 15 1 ra=0x55557088dc
1223040965: 47: 15 1 Total of 1
1223040967: 59: Dumping Not-Freed Pointers Changed Since Mark 47:
1223040967: 59: not freed: '0x1201f5f28|s3' (15 bytes) from 'ra=0x55557088dc'
1223040967: 59: total-size count source
1223040967: 59: 15 1 ra=0x55557088dc
1223040967: 59: 15 1 Total of 1
[...]
}}}
there a mem leak on each iteration. With gdb, the address 0x55557088dc is in
__GI___strdup:
{{{
(gdb) x 0x55557088dc
0x55557088dc <*__GI___strdup+60>: "\002 (-"
}}}
A breakpoint on this function and bt give me this:
{{{
Breakpoint 2, *__GI___strdup (s=0x55557c8b60 "/etc/localtime") at strdup.c:42
42 strdup.c: No such file or directory.
in strdup.c
(gdb) bt
#0 *__GI___strdup (s=0x55557c8b60 "/etc/localtime") at strdup.c:42
#1 0x000000555571cd2c in tzset_internal (always=<value optimized out>,
explicit=<value optimized out>) at tzset.c:194
#2 0x000000555571d6f0 in __tz_convert (timer=0xffffdedaf0, use_localtime=1,
tp=0xffffdedb68) at tzset.c:576
#3 0x000000555575f910 in *__GI___vsyslog_chk (pri=<value optimized out>,
flag=-1, fmt=0x1200096a8 "Hello World", ap=0xffffdedc20)
at ../misc/syslog.c:197
#4 0x000000555575ff88 in __syslog (pri=1434225504, fmt=0x55558decd8 "") at
../misc/syslog.c:119
#5 0x00000001200021d4 in main (argc=<value optimized out>, argv=<value
optimized out>) at test-leak-syslog.c:17
}}}
with TZ variable defined (like this: $ export
TZ=CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00), the dmalloc output is more cool:
{{{
1223040862: 6: Dmalloc version '5.5.2' from 'http://dmalloc.com/'
1223040862: 6: flags = 0x403, logfile '/tmp/test-leak-syslog.1256'
1223040862: 6: interval = 0, addr = 0, seen # = 0, limit = 0
1223040862: 6: starting time = 1223040862
1223040862: 6: process pid = 1256
1223040862: 6: WARNING: tried to free(0) from 'ra=0x555571e0e0'
1223040862: 12: Dumping Not-Freed Pointers Changed Since Start:
1223040862: 12: not freed: '0x1201f5f88|s1' (21 bytes) from 'ra=0x555571cb90'
1223040862: 12: not freed: '0x1201f5fc8|s1' (45 bytes) from 'ra=0x55557088dc'
1223040862: 12: not freed: '0x1201fbfe8|s1' (20 bytes) from 'ra=0x555571cb90'
1223040862: 12: total-size count source
1223040862: 12: 45 1 ra=0x55557088dc
1223040862: 12: 41 2 ra=0x555571cb90
1223040862: 12: 86 3 Total of 2
1223040864: 18: Dumping Not-Freed Pointers Changed Since Mark 12:
1223040864: 18: memory table is empty
1223040866: 24: Dumping Not-Freed Pointers Changed Since Mark 18:
1223040866: 24: memory table is empty
1223040868: 30: Dumping Not-Freed Pointers Changed Since Mark 24:
1223040868: 30: memory table is empty
1223040870: 36: Dumping Not-Freed Pointers Changed Since Mark 30:
1223040870: 36: memory table is empty
[...]
}}}
there are always leaks at start but no more leak after.
--
Summary: Leak in tzset_internal function when TZ environment
variable doesn't exist ?
Product: glibc
Version: 2.4
Status: NEW
Severity: normal
Priority: P2
Component: libc
AssignedTo: drepper at redhat dot com
ReportedBy: homer242 at gmail dot com
CC: glibc-bugs at sources dot redhat dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: mips64-octeon-linux-gnu
GCC target triplet: mips64-octeon-linux-gnu
http://sourceware.org/bugzilla/show_bug.cgi?id=6940
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.