|
From: Michael B A. <mb...@io...> - 2003-07-16 01:51:56
|
There are leaks in mbsrtowcs in my glibc-2.2.5:
==19983== 564 bytes in 1 blocks are still reachable in loss record 5 of 5
==19983== at 0x40166CCD: calloc (vg_clientfuncs.c:245)
==19983== by 0x40008A0B: _dl_new_object (in /lib/ld-2.2.5.so)
==19983== by 0x400049EE: _dl_map_object_from_fd (in /lib/ld-2.2.5.so)
==19983== by 0x40005DB6: _dl_map_object_internal (in /lib/ld-2.2.5.so)
==19983== by 0x42112187: dl_open_worker (in /lib/i686/libc-2.2.5.so)
==19983== by 0x4000B4B2: _dl_catch_error_internal (in /lib/ld-2.2.5.so)
==19983== by 0x42112760: _dl_open (in /lib/i686/libc-2.2.5.so)
==19983== by 0x42113490: do_dlopen (in /lib/i686/libc-2.2.5.so)
==19983== by 0x4000B4B2: _dl_catch_error_internal (in /lib/ld-2.2.5.so)
==19983== by 0x4211333B: __libc_dlopen (in /lib/i686/libc-2.2.5.so)
==19983== by 0x4202028B: __gconv_find_shlib (in /lib/i686/libc-2.2.5.so)
==19983== by 0x4201FC34: find_module (in /lib/i686/libc-2.2.5.so)
==19983== by 0x4201FEAE: __gconv_lookup_cache (in /lib/i686/libc-2.2.5.so)
==19983== by 0x42019498: __gconv_find_transform (in
/lib/i686/libc-2.2.5.so)
==19983== by 0x420A56B8: __wcsmbs_load_conv (in /lib/i686/libc-2.2.5.so)
==19983== by 0x420877DD: __mbsrtowcs (in /lib/i686/libc-2.2.5.so)
==19983== by 0x4022841C: cfg_load_env (src/cfg.c:234)
==19983== by 0x410471C2: ???
==19983== by 0x8048E62: run_suite (tmba.c:73)
==19983== by 0x80491B7: main (tmba.c:135)
I tried to add the following to /usr/local/lib/valgrid/default.supp:
{
test
Memcheck:Cond
fun:__mbsr*
}
but it had no effect. How do I supress these messages?
Thanks,
Mike
|
|
From: Nicholas N. <nj...@ca...> - 2003-07-20 16:55:11
|
On Tue, 15 Jul 2003, Michael B Allen wrote:
> There are leaks in mbsrtowcs in my glibc-2.2.5:
>
> ==19983== 564 bytes in 1 blocks are still reachable in loss record 5 of 5
> ==19983== at 0x40166CCD: calloc (vg_clientfuncs.c:245)
> ==19983== by 0x40008A0B: _dl_new_object (in /lib/ld-2.2.5.so)
> ==19983== by 0x400049EE: _dl_map_object_from_fd (in /lib/ld-2.2.5.so)
> ==19983== by 0x40005DB6: _dl_map_object_internal (in /lib/ld-2.2.5.so)
> ==19983== by 0x42112187: dl_open_worker (in /lib/i686/libc-2.2.5.so)
> ==19983== by 0x4000B4B2: _dl_catch_error_internal (in /lib/ld-2.2.5.so)
> ==19983== by 0x42112760: _dl_open (in /lib/i686/libc-2.2.5.so)
> ==19983== by 0x42113490: do_dlopen (in /lib/i686/libc-2.2.5.so)
> ==19983== by 0x4000B4B2: _dl_catch_error_internal (in /lib/ld-2.2.5.so)
> ==19983== by 0x4211333B: __libc_dlopen (in /lib/i686/libc-2.2.5.so)
> ==19983== by 0x4202028B: __gconv_find_shlib (in /lib/i686/libc-2.2.5.so)
> ==19983== by 0x4201FC34: find_module (in /lib/i686/libc-2.2.5.so)
> ==19983== by 0x4201FEAE: __gconv_lookup_cache (in /lib/i686/libc-2.2.5.so)
> ==19983== by 0x42019498: __gconv_find_transform (in
> /lib/i686/libc-2.2.5.so)
> ==19983== by 0x420A56B8: __wcsmbs_load_conv (in /lib/i686/libc-2.2.5.so)
> ==19983== by 0x420877DD: __mbsrtowcs (in /lib/i686/libc-2.2.5.so)
> ==19983== by 0x4022841C: cfg_load_env (src/cfg.c:234)
> ==19983== by 0x410471C2: ???
> ==19983== by 0x8048E62: run_suite (tmba.c:73)
> ==19983== by 0x80491B7: main (tmba.c:135)
>
> I tried to add the following to /usr/local/lib/valgrid/default.supp:
>
> {
> test
> Memcheck:Cond
> fun:__mbsr*
> }
>
> but it had no effect. How do I supress these messages?
The error type is "Leak", not "Cond".
The stack trace in suppressions must contain the top 1,2,3, or 4 functions
in the call trace, not just one from the middle.
Try this:
{
test
Memcheck:Leak
fun:calloc
fun:_dl_new_object
fun:_dl_map_object_from_fd
fun:_dl_map_object_internal
}
I think that's right.
Or use the --gen-suppression=yes option in the new 20030716 snapshot (from
developer.kde.org/~sewardj).
It's unfortunate that the functions at the top of the stack trace are so
generic in this case, but hopefully it won't matter.
N
|
|
From: Michael B A. <mb...@io...> - 2003-07-21 06:11:11
Attachments:
wildcmp.c
|
> It's unfortunate that the functions at the top of the stack trace are so > generic in this case, but hopefully it won't matter. > > N That might exclude all memory allocated by calloc! Is it completely infeasible to collect the violations and then walk each stack trace looking for matches? Provided the matching occured after the run was completed such a thing would not impact runtime performace. This makes me think of a neat piece of code I found somewhere. It does simple dos like wildcard marching. See the attached file with function wildcmp. If the input was an array of symbols (or some value representing the symbols) instead of an array of characters and the pattern was an array of symbols with every other element effectively being a '*' you could have a pretty sophisticated stack trace matching algorithm. Mike |
|
From: Nicholas N. <nj...@ca...> - 2003-07-21 07:45:21
|
On Mon, 21 Jul 2003, Michael B Allen wrote: > > It's unfortunate that the functions at the top of the stack trace are so > > generic in this case, but hopefully it won't matter. > > That might exclude all memory allocated by calloc! Why? If you only put a single function in the suppression, yes, but if you put four it should be ok, no? > Is it completely infeasible to collect the violations and then walk each > stack trace looking for matches? Provided the matching occured after the > run was completed such a thing would not impact runtime performace. Waiting until the run ended is not feasible -- what if Memcheck waited until the end of the run before telling you that your program was about to seg fault? More complex suppression/stack trace matching is possible at runtime. But there hasn't been much call for it so far, however, and we don't like adding complexity without good reason. (I guess this is the opportunity for everybody who has found the current suppression format too restrictive, but never said anything, to speak up...) N |