An other wierd behavior from valgrind.

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

An other wierd behavior from valgrind.

Eric Lauzon
Here is an example of code and below is represenation of
valgrind output which seem buggy.


char *protocol_names[256];

void InitProtoNames()
{

  struct protoent *pt;
  unsigned char *tmp;

  int i;
  u_char protoname[11];

  for(i = 0; i < 256; i++)
    {
      pt = getprotobynumber(i);

      if(pt)
        {
          protocol_names[i] = strdup(pt->p_name);

          tmp = protocol_names[i];

          for(tmp = protocol_names[i]; *tmp != 0; tmp++)
            *tmp = (unsigned char) toupper(*tmp);

        }
      else
        {
          snprintf(protoname, 10, "PROTO%03d", i);
          protocol_names[i] = strdup(protoname);
        }


    }
}

void DelProtoNames()
{
  int i;
  int len = 0;

  for(i = 0; i < 256; i++)
    {
      if(protocol_names[i])
        {
          len = strlen(protocol_names[i]);
          bzero(protocol_names[i],len);
          free(protocol_names[i]);
          protocol_names[i]=NULL;
        }
    }

}


Still valgrind report the following:
==6285== 8 bytes in 1 blocks are still reachable in loss record 1 of 16
==6285==    at 0x1B9022E8: malloc (vg_replace_malloc.c:130)
==6285==    by 0x1BA520AD: __nss_lookup_function (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA51E1E: __nss_lookup (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA53942: __nss_protocols_lookup (in
/lib/libc-2.3.4.so)
==6285==    by 0x1BA575ED: getprotobynumber_r@@GLIBC_2.1.2 (in
/lib/libc-2.3.4.so)
==6285==    by 0x1BA5743E: getprotobynumber (in /lib/libc-2.3.4.so)
==6285==    by 0x804BF38: InitProtoNames (util.c:286)
==6285==    by 0x8049A96: main (main.c:99)
==6285==
==6285==
==6285== 8 bytes in 1 blocks are still reachable in loss record 2 of 16
==6285==    at 0x1B9022E8: malloc (vg_replace_malloc.c:130)
==6285==    by 0x1BA522CE: nss_parse_file (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA51DD3: __nss_database_lookup (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA5391E: __nss_protocols_lookup (in
/lib/libc-2.3.4.so)
==6285==    by 0x1BA575ED: getprotobynumber_r@@GLIBC_2.1.2 (in
/lib/libc-2.3.4.so)
==6285==    by 0x1BA5743E: getprotobynumber (in /lib/libc-2.3.4.so)
==6285==    by 0x804BF38: InitProtoNames (util.c:286)
==6285==    by 0x8049A96: main (main.c:99)
==6285==
==6285== 16 bytes in 1 blocks are still reachable in loss record 5 of 16
==6285==    at 0x1B9022E8: malloc (vg_replace_malloc.c:130)
==6285==    by 0x1BA3FBF3: tsearch (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA5206C: __nss_lookup_function (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA51E1E: __nss_lookup (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA53942: __nss_protocols_lookup (in
/lib/libc-2.3.4.so)
==6285==    by 0x1BA575ED: getprotobynumber_r@@GLIBC_2.1.2 (in
/lib/libc-2.3.4.so)
==6285==    by 0x1BA5743E: getprotobynumber (in /lib/libc-2.3.4.so)
==6285==    by 0x804BF38: InitProtoNames (util.c:286)
==6285==    by 0x8049A96: main (main.c:99)
==6285== 23 bytes in 1 blocks are still reachable in loss record 6 of 16
==6285==    at 0x1B9022E8: malloc (vg_replace_malloc.c:130)
==6285==    by 0x1B8EC044: _dl_new_object (in /lib/ld-2.3.4.so)
==6285==    by 0x1B8E91EB: _dl_map_object_from_fd (in /lib/ld-2.3.4.so)
==6285==    by 0x1B8E7E1B: _dl_map_object (in /lib/ld-2.3.4.so)
==6285==    by 0x1BA74513: dl_open_worker (in /lib/libc-2.3.4.so)
==6285==    by 0x1B8EE785: _dl_catch_error (in /lib/ld-2.3.4.so)
==6285==    by 0x1BA7424F: _dl_open (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA7612E: do_dlopen (in /lib/libc-2.3.4.so)
==6285==    by 0x1B8EE785: _dl_catch_error (in /lib/ld-2.3.4.so)
==6285==    by 0x1BA75FA1: __libc_dlopen_mode (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA52214: __nss_lookup_function (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA51E1E: __nss_lookup (in /lib/libc-2.3.4.so)
==6285== 23 bytes in 1 blocks are still reachable in loss record 7 of 16
==6285==    at 0x1B9022E8: malloc (vg_replace_malloc.c:130)
==6285==    by 0x1B8E81B8: _dl_map_object (in /lib/ld-2.3.4.so)
==6285==    by 0x1BA74513: dl_open_worker (in /lib/libc-2.3.4.so)
==6285==    by 0x1B8EE785: _dl_catch_error (in /lib/ld-2.3.4.so)
==6285==    by 0x1BA7424F: _dl_open (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA7612E: do_dlopen (in /lib/libc-2.3.4.so)
==6285==    by 0x1B8EE785: _dl_catch_error (in /lib/ld-2.3.4.so)
==6285==    by 0x1BA75FA1: __libc_dlopen_mode (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA52214: __nss_lookup_function (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA51E1E: __nss_lookup (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA53942: __nss_protocols_lookup (in
/lib/libc-2.3.4.so)
==6285==    by 0x1BA575ED: getprotobynumber_r@@GLIBC_2.1.2 (in
/lib/libc-2.3.4.so)
==6285== 28 bytes in 1 blocks are still reachable in loss record 8 of 16
==6285==    at 0x1B9022E8: malloc (vg_replace_malloc.c:130)
==6285==    by 0x1B8ED6E5: _dl_map_object_deps (in /lib/ld-2.3.4.so)
==6285==    by 0x1BA7456C: dl_open_worker (in /lib/libc-2.3.4.so)
==6285==    by 0x1B8EE785: _dl_catch_error (in /lib/ld-2.3.4.so)
==6285==    by 0x1BA7424F: _dl_open (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA7612E: do_dlopen (in /lib/libc-2.3.4.so)
==6285==    by 0x1B8EE785: _dl_catch_error (in /lib/ld-2.3.4.so)
==6285==    by 0x1BA75FA1: __libc_dlopen_mode (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA52214: __nss_lookup_function (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA51E1E: __nss_lookup (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA53942: __nss_protocols_lookup (in
/lib/libc-2.3.4.so)
==6285==    by 0x1BA575ED: getprotobynumber_r@@GLIBC_2.1.2 (in
/lib/libc-2.3.4.so)
==6285== 144 bytes in 1 blocks are still reachable in loss record 10 of
16
==6285==    at 0x1B902C19: calloc (vg_replace_malloc.c:175)
==6285==    by 0x1B8EF85C: _dl_check_map_versions (in /lib/ld-2.3.4.so)
==6285==    by 0x1BA74974: dl_open_worker (in /lib/libc-2.3.4.so)
==6285==    by 0x1B8EE785: _dl_catch_error (in /lib/ld-2.3.4.so)
==6285==    by 0x1BA7424F: _dl_open (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA7612E: do_dlopen (in /lib/libc-2.3.4.so)
==6285==    by 0x1B8EE785: _dl_catch_error (in /lib/ld-2.3.4.so)
==6285==    by 0x1BA75FA1: __libc_dlopen_mode (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA52214: __nss_lookup_function (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA51E1E: __nss_lookup (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA53942: __nss_protocols_lookup (in
/lib/libc-2.3.4.so)
==6285==    by 0x1BA575ED: getprotobynumber_r@@GLIBC_2.1.2 (in
/lib/libc-2.3.4.so)
==6285== 209 bytes in 13 blocks are still reachable in loss record 12 of
16
==6285==    at 0x1B9022E8: malloc (vg_replace_malloc.c:130)
==6285==    by 0x1BA52B6C: nss_getline (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA52379: nss_parse_file (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA51DD3: __nss_database_lookup (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA5391E: __nss_protocols_lookup (in
/lib/libc-2.3.4.so)
==6285==    by 0x1BA575ED: getprotobynumber_r@@GLIBC_2.1.2 (in
/lib/libc-2.3.4.so)
==6285==    by 0x1BA5743E: getprotobynumber (in /lib/libc-2.3.4.so)
==6285==    by 0x804BF38: InitProtoNames (util.c:286)
==6285==    by 0x8049A96: main (main.c:99)


Other stuff from libc seem to be reported as reachable block (static
allocated lib data):
==6285== 48 bytes in 4 blocks are still reachable in loss record 9 of 16
==6285==    at 0x1B9022E8: malloc (vg_replace_malloc.c:130)
==6285==    by 0x1BA01A0B: __tzstring (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA03365: __tzfile_read (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA01BA3: tzset_internal (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA02527: __tz_convert (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA00DBE: localtime_r (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA3DD93: vsyslog (in /lib/libc-2.3.4.so)
==6285==    by 0x1BA3DCAE: syslog (in /lib/libc-2.3.4.so)
==6285==    by 0x804BB2C: LogMessage (util.c:76)
==6285==    by 0x8049ABB: main (main.c:104)


-elz


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. <a href="http://ads.osdn.com/?ad_idt77&alloc_id492&op=click">http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|

Re: An other wierd behavior from valgrind.

njn (Bugzilla)-2
On Fri, 17 Jun 2005, Eric Lauzon wrote:

> Here is an example of code and below is represenation of
> valgrind output which seem buggy.

Why do you think it is buggy?

N


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|

Re: An other wierd behavior from valgrind.

Scott Long
In reply to this post by Eric Lauzon
Eric Lauzon wrote:
> Here is an example of code and below is represenation of
> valgrind output which seem buggy.

I assume from your sig that you are a programmer for "AboveSecurity"
consulting services. Am I to assume that all programmers at this company
are of a similar skill level, e.g. unable to distinguish between an
application and its linked libraries, and using archaic functions such
as bzero()?

--
Scott Long   <[hidden email]>
Software Engineer
SwiftView, Inc.
(971) 223-2639


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|

RE: An other wierd behavior from valgrind.

Eric Lauzon
In reply to this post by Eric Lauzon
1: [bzero,memset] so valgring output reachable block because
   i use bzero instead of memeset? LOL.

2: beside compagny name bashing can you provide insightfull comment?

3: linked library? i dont see where the code snapshot needs any
   extra linked library to compile beside libc.

4: if you had bad experience in the past with anyone where i work
   i would appreciate you keep it betwen that person and you..

-elz



> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf
> Of Scott Long
> Sent: 20 juin 2005 12:09
> To: [hidden email]
> Subject: Re: [Valgrind-users] An other wierd behavior from valgrind.
>
> Eric Lauzon wrote:
> > Here is an example of code and below is represenation of valgrind
> > output which seem buggy.
>
> I assume from your sig that you are a programmer for "AboveSecurity"
> consulting services. Am I to assume that all programmers at
> this company are of a similar skill level, e.g. unable to
> distinguish between an application and its linked libraries,
> and using archaic functions such as bzero()?
>
> --
> Scott Long   <[hidden email]>
> Software Engineer
> SwiftView, Inc.
> (971) 223-2639
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration
> Strategies from IBM. Find simple to follow Roadmaps,
> straightforward articles, informative Webcasts and more! Get
> everything you need to get up to speed, fast.
> http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Valgrind-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. <a href="http://ads.osdn.com/?ad_idt77&alloc_id492&op=click">http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|

RE: An other wierd behavior from valgrind.

Igmar Palsenberg

> 1: [bzero,memset] so valgring output reachable block because
>    i use bzero instead of memeset? LOL.

bzero() is obsolete.
 
> 3: linked library? i dont see where the code snapshot needs any
>    extra linked library to compile beside libc.

Exactly. And if you look close at the error message, you'll se that the
memleak is in glibc, either because it is actually leaking, or you don't
properly handle those functions.

Since getprotobynumber() is using a static buffer, I suggest you switch to
getprotobynumber_r(), which is likely to solve your problem, or write a
supression. Valgrind is not at fault here.



        Igmar





-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users