valgrind-users

[Valgrind-users] Why doesn't valgrind detect a memory leak for my application

[Sanjay K. (sanjaku5) <san...@ci...>]

Hi,
     I run my program using valgrind to detect the memory leaks
valgrind -v --tool=memcheck --leak-check=full  ./binary -f conf.file


But it doesn't show leaks, even I create one leak  of 10000 bytes in the code.


Any wild guess ??

Thanks,
Sanjay

Re: [Valgrind-users] Why doesn't valgrind detect a memory leak for my application

[David C. <dcc...@ac...>]

On 6/12/2013 12:01 AM, Sanjay Kumar (sanjaku5) wrote:
>
> Hi,
>
>      I run my program using valgrind to detect the memory leaks
>
> valgrind -v --tool=memcheck --leak-check=full  ./binary -f conf.file
>
>
> But it doesn't show leaks, even I create one leak  of 10000 bytes in 
> the code.
>
> Any wild guess ??
>
>

What happens if you create a simple program that does nothing but 
allocate 10000 bytes and then exits?  I presume that the program you 
describe above cannot be posted on the Internet; try to create a test 
case as small as possible.

And of course it would be good to know what version of Valgrind you are 
using, and on what platform.

-- 
     David Chapman      dcc...@ac...
     Chapman Consulting -- San Jose, CA
     Software Development Done Right.
     www.chapman-consulting-sj.com

Re: [Valgrind-users] Why doesn't valgrind detect a memory leak for my application

[David C. <dcc...@ac...>]

Please reply to the group, not just me, and please don't top-post.  My 
reply is at the bottom.

On 6/12/2013 1:35 AM, Sanjay Kumar (sanjaku5) wrote:
>
> Hi David,
>
> Below is code which I added  to create the leak in my application :
>
> /*******************/
>
> char *mleak = NULL;
>
>     static int mcnt = 0;
>
>     mleak = (char *)malloc(10000);
>
>     if(NULL == mleak)
>
> printf("\nmleak is  NULL\n");
>
> strcpy(mleak, "aaaaaaaaaaaaaaaaaaaaaaa");
>
> printf("\nmleak called:%d mleak:%s \n", mcnt++, mleak);
>
> /*******************/
>
> Below is summary of report:
>
> ==11597== Memcheck, a memory error detector
>
> ==11597== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
>
> ==11597== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright 
> info
>
> ==11597== Command: ./flare -f syfer.conf
>
> ==11597==
>
> --11597-- Valgrind options:
>
> --11597--    -v
>
> --11597-- --tool=memcheck
>
> --11597-- --leak-check=full
>
> --11597-- --leak-resolution=high
>
> --11597-- Contents of /proc/version:
>
> --11597-- Linux version 2.6.38-staros-v3-40087-deb-32 (root@releng7) 
> (gcc version 3.3.5 (Debian 1:3.3.5-13)) #1 SMP PREEMPT Sat Oct 1 
> 02:50:26 EDT 2011
>
> --11597-- Arch and hwcaps: X86, x86-sse1-sse2
>
> --11597-- Page sizes: currently 4096, max supported 4096
>
> --11597-- Valgrind library directory: /usr/local/lib/valgrind
>
> --11597-- Reading syms from /usr/local/flare/flare
>
> --11597-- object doesn't have a dynamic symbol table
>
> --11597-- warning: DiCfSI 0x0 .. 0x0 outside mapped rw segments (NONE)
>
> --11597-- warning: DiCfSI 0x1 .. 0x2 outside mapped rw segments (NONE)
>
> --11597-- warning: DiCfSI 0x3 .. 0x8 outside mapped rw segments (NONE)
>
> --11597-- warning: DiCfSI 0x9 .. 0x437 outside mapped rw segments (NONE)
>
> --11597-- warning: DiCfSI 0x0 .. 0x0 outside mapped rw segments (NONE)
>
> --11597-- warning: DiCfSI 0x1 .. 0x2 outside mapped rw segments (NONE)
>
> --11597-- warning: DiCfSI 0x3 .. 0x8 outside mapped rw segments (NONE)
>
> --11597-- warning: DiCfSI 0x9 .. 0x3a6 outside mapped rw segments (NONE)
>
> --11597-- warning: DiCfSI 0x0 .. 0x0 outside mapped rw segments (NONE)
>
> --11597-- warning: DiCfSI 0x1 .. 0x2 outside mapped rw segments (NONE)
>
> --11597-- Reading syms from /usr/local/lib/valgrind/memcheck-x86-linux
>
> --11597-- object doesn't have a dynamic symbol table
>
> --11597-- Scheduler: using generic scheduler lock implementation.
>
> --11597-- Reading suppressions file: /usr/local/lib/valgrind/default.supp
>
> ==11597== embedded gdbserver: reading from 
> /tmp/vgdb-pipe-from-vgdb-to-11597-by-root-on-???
>
> ==11597== embedded gdbserver: writing to 
> /tmp/vgdb-pipe-to-vgdb-from-11597-by-root-on-???
>
> ==11597== embedded gdbserver: shared mem 
> /tmp/vgdb-pipe-shared-mem-vgdb-11597-by-root-on-???
>
> ==11597==
>
> ==11597==
>
> ==11597== TO CONTROL THIS PROCESS USING vgdb (which you probably
>
> ==11597== don't want to do, unless you know exactly what you're doing,
>
> ==11597== or are doing some strange experiment):
>
> ==11597== /usr/local/lib/valgrind/../../bin/vgdb --pid=11597 ...command...
>
> ==11597==
>
> ==11597== TO DEBUG THIS PROCESS USING GDB: start GDB like this
>
> ==11597== /path/to/gdb ./flare
>
> ==11597== and then give GDB the following command
>
> ==11597== target remote | /usr/local/lib/valgrind/../../bin/vgdb 
> --pid=11597
>
> ==11597== --pid is optional if only one valgrind process is running
>
> ==11597==
>
> ==11597== Conditional jump or move depends on uninitialised value(s)
>
> ==11597==    at 0x8A838B5: __register_atfork (in /usr/local/flare/flare)
>
> ==11597==    by 0x8A68074: ptmalloc_init (in /usr/local/flare/flare)
>
> ==11597==    by 0x8A6C265: malloc_hook_ini (in /usr/local/flare/flare)
>
> ==11597==    by 0x8A6BDCE: malloc (in /usr/local/flare/flare)
>
> ==11597==    by 0x8AA893B: _dl_init_paths (in /usr/local/flare/flare)
>
> ==11597==    by 0x8A8BDBB: _dl_non_dynamic_init (in 
> /usr/local/flare/flare)
>
> ==11597==    by 0x8A8CA75: __libc_init_first (in /usr/local/flare/flare)
>
> ==11597==    by 0x8A3E460: (below main) (in /usr/local/flare/flare)
>
> ==11597==
>
> ==11597== Conditional jump or move depends on uninitialised value(s)
>
> ==11597==    at 0x8A83926: __register_atfork (in /usr/local/flare/flare)
>
> ==11597==    by 0x8A68074: ptmalloc_init (in /usr/local/flare/flare)
>
> ==11597==    by 0x8A6C265: malloc_hook_ini (in /usr/local/flare/flare)
>
> ==11597==    by 0x8A6BDCE: malloc (in /usr/local/flare/flare)
>
> ==11597==    by 0x8AA893B: _dl_init_paths (in /usr/local/flare/flare)
>
> ==11597==    by 0x8A8BDBB: _dl_non_dynamic_init (in 
> /usr/local/flare/flare)
>
> ==11597==    by 0x8A8CA75: __libc_init_first (in /usr/local/flare/flare)
>
> ==11597==    by 0x8A3E460: (below main) (in /usr/local/flare/flare)
>
> ......
>
> ...........
>
> .............
>
> ==11597==
>
> ==11597== 481512 errors in context 998 of 1000:
>
> ==11597== Invalid read of size 4
>
> ==11597==    at 0x8A6FBCF: memcpy (in /usr/local/flare/flare)
>
> ==11597==    by 0x80D9F80: 
> configuration::cfgparams::read_pattern(std::string, std::string, 
> fsm_t*) (stl_iterator.h:704)
>
> ==11597==    by 0x8086EE2: 
> configuration::cfg::read_pattern(configuration::configfile*, 
> std::string, bool, unsigned short) (cfgdata.cpp:1684)
>
> ==11597==    by 0x8088215: configuration::cfg::read_pattern_file() 
> (cfgdata.cpp:780)
>
> ==11597==    by 0x809935B: configuration::cfg::read_config_file() 
> (cfgdata.cpp:623)
>
> ==11597==    by 0x811576D: main (main.cpp:3930)
>
> ==11597== Address 0xbef88714 is on thread 1's stack
>
> ==11597==
>
> ==11597==
>
> ==11597== 481512 errors in context 999 of 1000:
>
> ==11597== Invalid read of size 4
>
> ==11597==    at 0x8A6FBCF: memcpy (in /usr/local/flare/flare)
>
> ==11597==    by 0x80D9CD4: 
> configuration::cfgparams::read_pattern(std::string, std::string, 
> fsm_t*) (stl_iterator.h:704)
>
> ==11597==    by 0x8086EE2: 
> configuration::cfg::read_pattern(configuration::configfile*, 
> std::string, bool, unsigned short) (cfgdata.cpp:1684)
>
> ==11597==    by 0x8088215: configuration::cfg::read_pattern_file() 
> (cfgdata.cpp:780)
>
> ==11597==    by 0x809935B: configuration::cfg::read_config_file() 
> (cfgdata.cpp:623)
>
> ==11597==    by 0x811576D: main (main.cpp:3930)
>
> ==11597== Address 0xbefc3388 is on thread 1's stack
>
> ==11597==
>
> ==11597==
>
> ==11597== 662079 errors in context 1000 of 1000:
>
> ==11597== Invalid read of size 4
>
> ==11597==    at 0x8A6FBCF: memcpy (in /usr/local/flare/flare)
>
> ==11597==    by 0x80DC54B: void 
> std::__uninitialized_fill_n_aux<__gnu_cxx::__normal_iterator<flare_stack*, 
> std::vector<flare_stack, std::allocator<flare_stack> > >, unsigned 
> int, flare_stack>(__gnu_cxx::__normal_iterator<flare_stack*, 
> std::vector<flare_stack, std::allocator<flare_stack> > >, unsigned 
> int, flare_stack const&, __false_type) (stl_construct.h:81)
>
> ==11597==    by 0x80DEAE5: std::vector<flare_stack, 
> std::allocator<flare_stack> 
> >::_M_fill_insert(__gnu_cxx::__normal_iterator<flare_stack*, 
> std::vector<flare_stack, std::allocator<flare_stack> > >, unsigned 
> int, flare_stack const&) (vector.tcc:365)
>
> ==11597==    by 0x80DB8C4: 
> configuration::cfgparams::read_pattern(std::string, std::string, 
> fsm_t*) (stl_vector.h:658)
>
> ==11597==    by 0x8086EE2: 
> configuration::cfg::read_pattern(configuration::configfile*, 
> std::string, bool, unsigned short) (cfgdata.cpp:1684)
>
> ==11597==    by 0x8088215: configuration::cfg::read_pattern_file() 
> (cfgdata.cpp:780)
>
> ==11597==    by 0x809935B: configuration::cfg::read_config_file() 
> (cfgdata.cpp:623)
>
> ==11597==    by 0x811576D: main (main.cpp:3930)
>
> ==11597== Address 0xbedb2374 is on thread 1's stack
>
> ==11597==
>
> ==11597== ERROR SUMMARY: 3704242 errors from 1000 contexts 
> (suppressed: 0 from 0)
>
> *When the same code I run as test program valgrind able to detect the 
> leak.*
>
> *But NOT when it is part of my application.***
>
> Thanks,
>
> Sanjay
>

I'll leave the details of why leaks would not be reported to the 
Valgrind development team.  But it seems to me that you have plenty to 
work on already:  3,704,242 errors of various kinds.  If these are 
cleaned up, what happens then?

I suppose it is possible that Valgrind doesn't notice leaks among all of 
the other reports, but IMO that is a much smaller problem than reading 
out-of-bounds memory and executing instructions based on uninitialized 
data.  My goal is always zero errors from Valgrind, even if the program 
seems to work fine without any changes.  Fix the errors that Valgrind 
reports now and let us know if there are still problems with leak reporting.

-- 
     David Chapman      dcc...@ac...
     Chapman Consulting -- San Jose, CA
     Software Development Done Right.
     www.chapman-consulting-sj.com

Re: [Valgrind-users] Why doesn't valgrind detect a memory leak for my application

[Philippe W. <phi...@sk...>]

Sanjay,
> > --11597--    object doesn't have a dynamic symbol table
With the above
and the below stacktrace, it looks like this application is statically linked
(or at least, the malloc lib is statically linked).
valgrind can find leaks if malloc lib is statically linked
(you need to use --soname-synonyms=.... to indicate malloc is statically linked).
However, a completely statically linked application causes other problems.
You should have at least one (even dummy) dynamically linked lib to
have the dynamic loader be invoked in your process otherwise
valgrind cannot "LD_PRELOAD" some of its own .so.

Philippe

> > ==11597== Conditional jump or move depends on uninitialised value(s)
> > 
> > ==11597==    at 0x8A838B5: __register_atfork
> > (in /usr/local/flare/flare)
> > 
> > ==11597==    by 0x8A68074: ptmalloc_init (in /usr/local/flare/flare)
> > 
> > ==11597==    by 0x8A6C265: malloc_hook_ini
> > (in /usr/local/flare/flare)
> > 
> > ==11597==    by 0x8A6BDCE: malloc (in /usr/local/flare/flare)
> > 
> > ==11597==    by 0x8AA893B: _dl_init_paths
> > (in /usr/local/flare/flare)
> > 
> > ==11597==    by 0x8A8BDBB: _dl_non_dynamic_init
> > (in /usr/local/flare/flare)
> > 
> > ==11597==    by 0x8A8CA75: __libc_init_first
> > (in /usr/local/flare/flare)
> > 
> > ==11597==    by 0x8A3E460: (below main) (in /usr/local/flare/flare)

Re: [Valgrind-users] Why doesn't valgrind detect a memory leak for my application

[Sanjay K. (sanjaku5) <san...@ci...>]

Hi Philippe,
Below is part of Make file where I have done the Linking:

sslLIB=$(OUT_DIR)/libsyfer_ssl.a

# pull in dependency info for *existing* .o files
*********************************
-include $(commonOBJS:.o=.d)
-include $(sslOBJS:.o=.d)
-include $(cliCOMMONOBJS:.o=.d)
-include $(cliCLIOBJS:.o=.d)
-include $(cliSYFERSERVEROBJS:.o=.d)
-include $(cliSYFERCARDSERVEROBJS:.o=.d)
-include $(cliETHSERVERSERVEROBJS:.o=.d)

all: $(OUT_DIR)/$(OUTNAME) $(OUT_DIR)/cli

$(OUT_DIR)/cli : $(cliCOMMONOBJS) $(cliCLIOBJS)
    @echo "LL $(LOPTS) $@" $(REDIRECT)
    $(SILENT)$(LL) $(LOPTS) $(cliCOMMONOBJS) $(cliCLIOBJS)  -o cli -lpthread

$(OUT_DIR)/$(OUTNAME): $(VERSION_FILE) $(commonOBJS) $(sslLIB) $(cliCOMMONOBJS) $(cliSYFERSERVEROBJS)
    @echo "LL $(LOPTS) $@" $(REDIRECT)
    $(SILENT)$(LL) $(LOPTS) $(commonOBJS) $(cliCOMMONOBJS) $(cliSYFERSERVEROBJS) ./libs/librohc.a $(LIB_GLIB_DIR)/libglib-2.0.a ./libs/libsnutils.a ./libs/libcommon.a ./libs/libasnbase.a ./libs/libs1apgen.a ./libs/libsctp.a ./libs/libpcap.a $(LIB_PATH) -lssp -lsyfer_ssl -lcrypto -leventbridge -ldl -o $(OUTNAME)

$(OUT_DIR)/syfercard : $(cliCOMMONOBJS) $(cliSYFERCARDSERVEROBJS)
    @echo "LL $(LOPTS) $@" $(REDIRECT)
    $(SILENT)$(LL) $(LOPTS) $(cliCOMMONOBJS) $(cliSYFERCARDSERVEROBJS)  -o syfercard

$(OUT_DIR)/ethserver : $(cliCOMMONOBJS) $(cliETHSERVERSERVEROBJS)
    @echo "LL $(LOPTS) $@" $(REDIRECT)
    $(SILENT)$(LL) $(LOPTS) $(cliCOMMONOBJS) $(cliETHSERVERSERVEROBJS)  -o ethserver -lpthread

*********************************

Could you please comments on this.
What modification I need to do here ?

Thanks,
Sanjay

-----Original Message-----
From: Philippe Waroquiers [mailto:phi...@sk...] 
Sent: Thursday, June 13, 2013 1:38 AM
To: David Chapman
Cc: Sanjay Kumar (sanjaku5); val...@li...
Subject: Re: [Valgrind-users] Why doesn't valgrind detect a memory leak for my application

Sanjay,
> > --11597--    object doesn't have a dynamic symbol table
With the above
and the below stacktrace, it looks like this application is statically linked (or at least, the malloc lib is statically linked).
valgrind can find leaks if malloc lib is statically linked (you need to use --soname-synonyms=.... to indicate malloc is statically linked).
However, a completely statically linked application causes other problems.
You should have at least one (even dummy) dynamically linked lib to have the dynamic loader be invoked in your process otherwise valgrind cannot "LD_PRELOAD" some of its own .so.

Philippe

> > ==11597== Conditional jump or move depends on uninitialised value(s)
> > 
> > ==11597==    at 0x8A838B5: __register_atfork
> > (in /usr/local/flare/flare)
> > 
> > ==11597==    by 0x8A68074: ptmalloc_init (in /usr/local/flare/flare)
> > 
> > ==11597==    by 0x8A6C265: malloc_hook_ini
> > (in /usr/local/flare/flare)
> > 
> > ==11597==    by 0x8A6BDCE: malloc (in /usr/local/flare/flare)
> > 
> > ==11597==    by 0x8AA893B: _dl_init_paths
> > (in /usr/local/flare/flare)
> > 
> > ==11597==    by 0x8A8BDBB: _dl_non_dynamic_init
> > (in /usr/local/flare/flare)
> > 
> > ==11597==    by 0x8A8CA75: __libc_init_first
> > (in /usr/local/flare/flare)
> > 
> > ==11597==    by 0x8A3E460: (below main) (in /usr/local/flare/flare)

Re: [Valgrind-users] Why doesn't valgrind detect a memory leak for my application

[David C. <dcc...@ac...>]

On 6/12/2013 10:29 PM, Sanjay Kumar (sanjaku5) wrote:
> Hi Philippe,
> Below is part of Make file where I have done the Linking:
>
> sslLIB=$(OUT_DIR)/libsyfer_ssl.a
>
> # pull in dependency info for *existing* .o files
> *********************************
> -include $(commonOBJS:.o=.d)
> -include $(sslOBJS:.o=.d)
> -include $(cliCOMMONOBJS:.o=.d)
> -include $(cliCLIOBJS:.o=.d)
> -include $(cliSYFERSERVEROBJS:.o=.d)
> -include $(cliSYFERCARDSERVEROBJS:.o=.d)
> -include $(cliETHSERVERSERVEROBJS:.o=.d)
>
> all: $(OUT_DIR)/$(OUTNAME) $(OUT_DIR)/cli
>
> $(OUT_DIR)/cli : $(cliCOMMONOBJS) $(cliCLIOBJS)
>      @echo "LL $(LOPTS) $@" $(REDIRECT)
>      $(SILENT)$(LL) $(LOPTS) $(cliCOMMONOBJS) $(cliCLIOBJS)  -o cli -lpthread
>
> $(OUT_DIR)/$(OUTNAME): $(VERSION_FILE) $(commonOBJS) $(sslLIB) $(cliCOMMONOBJS) $(cliSYFERSERVEROBJS)
>      @echo "LL $(LOPTS) $@" $(REDIRECT)
>      $(SILENT)$(LL) $(LOPTS) $(commonOBJS) $(cliCOMMONOBJS) $(cliSYFERSERVEROBJS) ./libs/librohc.a $(LIB_GLIB_DIR)/libglib-2.0.a ./libs/libsnutils.a ./libs/libcommon.a ./libs/libasnbase.a ./libs/libs1apgen.a ./libs/libsctp.a ./libs/libpcap.a $(LIB_PATH) -lssp -lsyfer_ssl -lcrypto -leventbridge -ldl -o $(OUTNAME)

Without knowing the exact link options, there is no way for anyone on 
this list to determine what is going wrong.  Please paste the link 
command as printed during the build process, perhaps with proprietary 
object file names stripped out.  We don't know what, for example, 
"$(LOPTS)" expands to, and even "$(LL)" could have some linker flags in 
it.  These are your Makefile's definitions; they are not universal.


>
> $(OUT_DIR)/syfercard : $(cliCOMMONOBJS) $(cliSYFERCARDSERVEROBJS)
>      @echo "LL $(LOPTS) $@" $(REDIRECT)
>      $(SILENT)$(LL) $(LOPTS) $(cliCOMMONOBJS) $(cliSYFERCARDSERVEROBJS)  -o syfercard
>
> $(OUT_DIR)/ethserver : $(cliCOMMONOBJS) $(cliETHSERVERSERVEROBJS)
>      @echo "LL $(LOPTS) $@" $(REDIRECT)
>      $(SILENT)$(LL) $(LOPTS) $(cliCOMMONOBJS) $(cliETHSERVERSERVEROBJS)  -o ethserver -lpthread
>
> *********************************
>
> Could you please comments on this.
> What modification I need to do here ?
>
> Thanks,
> Sanjay
>
> -----Original Message-----
> From: Philippe Waroquiers [mailto:phi...@sk...]
> Sent: Thursday, June 13, 2013 1:38 AM
> To: David Chapman
> Cc: Sanjay Kumar (sanjaku5); val...@li...
> Subject: Re: [Valgrind-users] Why doesn't valgrind detect a memory leak for my application
>
> Sanjay,
>>> --11597--    object doesn't have a dynamic symbol table
> With the above
> and the below stacktrace, it looks like this application is statically linked (or at least, the malloc lib is statically linked).
> valgrind can find leaks if malloc lib is statically linked (you need to use --soname-synonyms=.... to indicate malloc is statically linked).
> However, a completely statically linked application causes other problems.
> You should have at least one (even dummy) dynamically linked lib to have the dynamic loader be invoked in your process otherwise valgrind cannot "LD_PRELOAD" some of its own .so.
>
> Philippe
>
>>> ==11597== Conditional jump or move depends on uninitialised value(s)
>>>
>>> ==11597==    at 0x8A838B5: __register_atfork
>>> (in /usr/local/flare/flare)
>>>
>>> ==11597==    by 0x8A68074: ptmalloc_init (in /usr/local/flare/flare)
>>>
>>> ==11597==    by 0x8A6C265: malloc_hook_ini
>>> (in /usr/local/flare/flare)
>>>
>>> ==11597==    by 0x8A6BDCE: malloc (in /usr/local/flare/flare)
>>>
>>> ==11597==    by 0x8AA893B: _dl_init_paths
>>> (in /usr/local/flare/flare)
>>>
>>> ==11597==    by 0x8A8BDBB: _dl_non_dynamic_init
>>> (in /usr/local/flare/flare)
>>>
>>> ==11597==    by 0x8A8CA75: __libc_init_first
>>> (in /usr/local/flare/flare)
>>>
>>> ==11597==    by 0x8A3E460: (below main) (in /usr/local/flare/flare)
>
>
>
>


-- 
     David Chapman      dcc...@ac...
     Chapman Consulting -- San Jose, CA
     Software Development Done Right.
     www.chapman-consulting-sj.com

Re: [Valgrind-users] Why doesn't valgrind detect a memory leak for my application

[Sanjay K. (sanjaku5) <san...@ci...>]

Hi David,

Below is final link command, printing at time linking, Please comments.
Thanks,
Sanjay


/auto/mitg-sw/tools/bintools/rhel-x86_64/gcc/201203161400/bin/g++ -m32 -MM -Wextra -Werror -Wno-deprecated -fno-strict-aliasing -g -DMC2 -O0 -fstack-protecto
r-all -ffast-math -DDEBUG -DFSM_STAT -DHAS_AF_PACKET -DSYFER_IP_SPECIFIC -I ../syfer_ssl/openssl-0.9.8g/include/ -I ../syfer_ssl/ -I ../syfer_ssl/nitrox-driv
er/cavium/software/include/ -I ../../framework -I ../../framework//utils/protocols/s1apgen -I ../../framework//cli/libs/snutils/include -I ../../framework//u
tils/common -I ../../framework//utils/asnbase -I ../../framework//utils/snutils -I -I../../framework//utils/protocols/hnbapgen -I../../framework//utils/proto
cols/ranapgen -I../../framework//utils/protocols/s1apgen -I../../framework//utils/protocols/ruagen -I../../framework//utils/protocols/gmmgen -I../../framewor
k//utils/protocols/sabpgen -I../../framework//utils/protocols/gtpgen -I ../../framework/ -I ../../framework//common/includes -I ../../framework//cli/libs/snu
tils/include -I ../../framework//cli/libs/glib-2.0.0/include -I ../../framework//cli/libs/glib-2.0.0/include/glib -I ../../framework//cli/libs/libedit/include -I ../../framework//cli/libs/libash/include -I ../../framework//cli/libs/libevent-1.4.8-stable/include -I ../../framework//cli/libs/pccts/h -I../../framework//eventbridge ../cli/syfer/CliHandlerServerSyfer.cpp > CliHandlerServerSyfer.d

/auto/mitg-sw/tools/bintools/rhel-x86_64/gcc/201203161400/bin/g++ -m32 -L /auto/mitg-sw/tools/bintools/rhel-x86_64/gcc/201203161400/lib --static -O0 -DFSM_STAT -DHAS_AF_PACKET ./base_instance.o ./configfile.o ./config.o ./logging.o ./message_buffer.o ./timer.o ./ip_entity.o ./ip_container.o ./pcap_filter.o ./cfgdata.o ./ikev2_cfgdata.o ./cfgparams.o ./main.o ./flare_app.o ./load_app.o ./cli.o ./statistics.o ./sgsn.o ./sgsn_ipv4_addr.o ./user.o ./user_entity.o ./user_cfgparams.o ./gmm.o ./gmm_entity.o ./gmm_cfgparams.o ./nas_common.o ./aes.o ./mac_md5.o ./snow_3g.o ./uia2.o ./uea2.o ./snx_sha256.o ./NasSecurity.o ./esm.o ./esm_entity.o ./esm_cfgparams.o ./emm.o ./emm_entity.o ./emm_cfgparams.o ./smc.o ./smc_entity.o ./smc_cfgparams.o ./smr.o ./smr_entity.o ./smr_cfgparams.o ./smtl.o ./smtl_entity.o ./smtl_cfgparams.o ./sm.o ./sm_entity.o ./sm_cfgparams.o ./sndcp.o ./sndcp_entity.o ./sndcp_cfgparams.o ./gea1.o ./gea2.o ./gea3.o ./llc.o ./llc_entity.o ./llc_cfgparams.o ./bssgp.o ./bssgp_entity.o ./bssgp_cfgparams.o ./ns.o ./ns_entity.o ./ns_cfgparams.o ./nsvc_entity.o ./m3ua.o ./m3ua_entity.o ./m3ua_cfgparams.o ./m3ua_transport_entity.o ./ns_ip_entity.o ./gtpcv0.o ./gtpcv0_entity.o ./gtpcv0_cfgparams.o ./gtpcv1.o ./gtpcv1_entity.o ./gtpcv1_cfgparams.o ./gtpcv2.o ./gtpcv2_entity.o ./gtpcv2_cfgparams.o ./gtpu_entity.o ./gtpu.o ./gtpu_cfgparams.o ./ranap_entity.o ./ranap.o ./ranap_cfgparams.o ./S1apMsgs.o ./s1ap.o ./s1ap_entity.o ./s1ap_cfgparams.o ./sccp_entity.o ./sccp.o ./sccp_cfgparams.o ./mapss7.o ./mapss7_entity.o ./mapss7_cfgparams.o ./cap.o ./cap_entity.o ./cap_cfgparams.o ./tcap.o ./tcap_entity.o ./tcap_cfgparams.o ./diameter.o ./diameter_entity.o ./diameter_cfgparams.o ./radius.o ./radius_entity.o ./radius_cfgparams.o ./ikev2.o ./ikev2_entity.o ./ikev2_entity_responder.o ./ikev2_entity_informational.o ./ikev2_entity_child.o ./ikev2_cfgparams.o ./ikev2_payload.o ./ikev2_crypto.o ./aka.o ./ikev2_eap_common.o ./ikev2_eap_aka.o ./ikev2_eap_sim.o ./ipsec_data.o ./ipsec_data_cfgparams.o ./ipsec_data_entity.o ./ipsec_esp_entity.o ./sha1.o ./sha1-internal.o ./xfrm.o ./xfrm_entity.o ./xfrm_load_entity.o ./xfrm_cfgparams.o ./xfrm_message.o ./bssap.o ./bssap_entity.o ./bssap_cfgparams.o ./traffic.o ./tlv.o ./gx.o ./asn.o ./stargen.o ./eventbridge.o ./CliAttrib.o ./CliObject.o ./CliCommand.o ./CliObjectSyfer.o ./CliObjectSyferCard.o ./CliObjectEth.o  ./CliHandlerServer.o ./CliHandlerServerSyfer.o  ./libs/librohc.a ../../framework//cli/libs/glib-2.0.0/lib/libglib-2.0.a ./libs/libsnutils.a ./libs/libcommon.a ./libs/libasnbase.a ./libs/libs1apgen.a ./libs/libsctp.a ./libs/libpcap.a -L . -L ../syfer_ssl/openssl-0.9.8g/ -L../../framework//eventbridge -lssp -lsyfer_ssl -lcrypto -leventbridge -ldl -o flare
./libs/libpcap.a(nametoaddr.o): In function `pcap_nametoaddrinfo':
nametoaddr.c:(.text+0xa3): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
./libs/libpcap.a(nametoaddr.o): In function `pcap_nametoaddr':
nametoaddr.c:(.text+0x1a): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
./libs/libpcap.a(nametoaddr.o): In function `pcap_nametonetaddr':
nametoaddr.c:(.text+0xdb): warning: Using 'getnetbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
./libs/libpcap.a(nametoaddr.o): In function `pcap_nametoproto':
nametoaddr.c:(.text+0x2cb): warning: Using 'getprotobyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
./libs/libpcap.a(nametoaddr.o): In function `pcap_nametoport':
nametoaddr.c:(.text+0x12f): warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking





-----Original Message-----
From: David Chapman [mailto:dcc...@ac...] 
Sent: Thursday, June 13, 2013 11:57 AM
To: Sanjay Kumar (sanjaku5)
Cc: Philippe Waroquiers; val...@li...
Subject: Re: [Valgrind-users] Why doesn't valgrind detect a memory leak for my application

On 6/12/2013 10:29 PM, Sanjay Kumar (sanjaku5) wrote:
> Hi Philippe,
> Below is part of Make file where I have done the Linking:
>
> sslLIB=$(OUT_DIR)/libsyfer_ssl.a
>
> # pull in dependency info for *existing* .o files
> *********************************
> -include $(commonOBJS:.o=.d)
> -include $(sslOBJS:.o=.d)
> -include $(cliCOMMONOBJS:.o=.d)
> -include $(cliCLIOBJS:.o=.d)
> -include $(cliSYFERSERVEROBJS:.o=.d)
> -include $(cliSYFERCARDSERVEROBJS:.o=.d) -include 
> $(cliETHSERVERSERVEROBJS:.o=.d)
>
> all: $(OUT_DIR)/$(OUTNAME) $(OUT_DIR)/cli
>
> $(OUT_DIR)/cli : $(cliCOMMONOBJS) $(cliCLIOBJS)
>      @echo "LL $(LOPTS) $@" $(REDIRECT)
>      $(SILENT)$(LL) $(LOPTS) $(cliCOMMONOBJS) $(cliCLIOBJS)  -o cli 
> -lpthread
>
> $(OUT_DIR)/$(OUTNAME): $(VERSION_FILE) $(commonOBJS) $(sslLIB) $(cliCOMMONOBJS) $(cliSYFERSERVEROBJS)
>      @echo "LL $(LOPTS) $@" $(REDIRECT)
>      $(SILENT)$(LL) $(LOPTS) $(commonOBJS) $(cliCOMMONOBJS) 
> $(cliSYFERSERVEROBJS) ./libs/librohc.a $(LIB_GLIB_DIR)/libglib-2.0.a 
> ./libs/libsnutils.a ./libs/libcommon.a ./libs/libasnbase.a 
> ./libs/libs1apgen.a ./libs/libsctp.a ./libs/libpcap.a $(LIB_PATH) 
> -lssp -lsyfer_ssl -lcrypto -leventbridge -ldl -o $(OUTNAME)

Without knowing the exact link options, there is no way for anyone on this list to determine what is going wrong.  Please paste the link command as printed during the build process, perhaps with proprietary object file names stripped out.  We don't know what, for example, "$(LOPTS)" expands to, and even "$(LL)" could have some linker flags in it.  These are your Makefile's definitions; they are not universal.


>
> $(OUT_DIR)/syfercard : $(cliCOMMONOBJS) $(cliSYFERCARDSERVEROBJS)
>      @echo "LL $(LOPTS) $@" $(REDIRECT)
>      $(SILENT)$(LL) $(LOPTS) $(cliCOMMONOBJS) 
> $(cliSYFERCARDSERVEROBJS)  -o syfercard
>
> $(OUT_DIR)/ethserver : $(cliCOMMONOBJS) $(cliETHSERVERSERVEROBJS)
>      @echo "LL $(LOPTS) $@" $(REDIRECT)
>      $(SILENT)$(LL) $(LOPTS) $(cliCOMMONOBJS) 
> $(cliETHSERVERSERVEROBJS)  -o ethserver -lpthread
>
> *********************************
>
> Could you please comments on this.
> What modification I need to do here ?
>
> Thanks,
> Sanjay
>
> -----Original Message-----
> From: Philippe Waroquiers [mailto:phi...@sk...]
> Sent: Thursday, June 13, 2013 1:38 AM
> To: David Chapman
> Cc: Sanjay Kumar (sanjaku5); val...@li...
> Subject: Re: [Valgrind-users] Why doesn't valgrind detect a memory 
> leak for my application
>
> Sanjay,
>>> --11597--    object doesn't have a dynamic symbol table
> With the above
> and the below stacktrace, it looks like this application is statically linked (or at least, the malloc lib is statically linked).
> valgrind can find leaks if malloc lib is statically linked (you need to use --soname-synonyms=.... to indicate malloc is statically linked).
> However, a completely statically linked application causes other problems.
> You should have at least one (even dummy) dynamically linked lib to have the dynamic loader be invoked in your process otherwise valgrind cannot "LD_PRELOAD" some of its own .so.
>
> Philippe
>
>>> ==11597== Conditional jump or move depends on uninitialised value(s)
>>>
>>> ==11597==    at 0x8A838B5: __register_atfork
>>> (in /usr/local/flare/flare)
>>>
>>> ==11597==    by 0x8A68074: ptmalloc_init (in /usr/local/flare/flare)
>>>
>>> ==11597==    by 0x8A6C265: malloc_hook_ini
>>> (in /usr/local/flare/flare)
>>>
>>> ==11597==    by 0x8A6BDCE: malloc (in /usr/local/flare/flare)
>>>
>>> ==11597==    by 0x8AA893B: _dl_init_paths
>>> (in /usr/local/flare/flare)
>>>
>>> ==11597==    by 0x8A8BDBB: _dl_non_dynamic_init
>>> (in /usr/local/flare/flare)
>>>
>>> ==11597==    by 0x8A8CA75: __libc_init_first
>>> (in /usr/local/flare/flare)
>>>
>>> ==11597==    by 0x8A3E460: (below main) (in /usr/local/flare/flare)
>
>
>
>


-- 
     David Chapman      dcc...@ac...
     Chapman Consulting -- San Jose, CA
     Software Development Done Right.
     www.chapman-consulting-sj.com

Re: [Valgrind-users] Why doesn't valgrind detect a memory leak for my application

[David C. <dcc...@ac...>]

Please don't top-post.

On 6/13/2013 12:26 AM, Sanjay Kumar (sanjaku5) wrote:
> Hi David,
>
> Below is final link command, printing at time linking, Please comments.
> Thanks,
> Sanjay
>
>
> <snip>
>
> /auto/mitg-sw/tools/bintools/rhel-x86_64/gcc/201203161400/bin/g++ -m32 -L /auto/mitg-sw/tools/bintools/rhel-x86_64/gcc/201203161400/lib --static -O0 -DFSM_STAT

The "--static" here is most likely the problem.  The g++ option for 
static linking is actually called "-static" (only one dash in front) but 
it looks like g++ is interpreting the two dashes as if they were one.

> -DHAS_AF_PACKET ./base_instance.o ./configfile.o ./config.o ./logging.o ./message_buffer.o ./timer.o ./ip_entity.o ./ip_container.o ./pcap_filter.o ./cfgdata.o ./ikev2_cfgdata.o ./cfgparams.o ./main.o ./flare_app.o ./load_app.o ./cli.o ./statistics.o ./sgsn.o ./sgsn_ipv4_addr.o ./user.o ./user_entity.o ./user_cfgparams.o ./gmm.o ./gmm_entity.o ./gmm_cfgparams.o ./nas_common.o ./aes.o ./mac_md5.o ./snow_3g.o ./uia2.o ./uea2.o ./snx_sha256.o ./NasSecurity.o ./esm.o ./esm_entity.o ./esm_cfgparams.o ./emm.o ./emm_entity.o ./emm_cfgparams.o ./smc.o ./smc_entity.o ./smc_cfgparams.o ./smr.o ./smr_entity.o ./smr_cfgparams.o ./smtl.o ./smtl_entity.o ./smtl_cfgparams.o ./sm.o ./sm_entity.o ./sm_cfgparams.o ./sndcp.o ./sndcp_entity.o ./sndcp_cfgparams.o ./gea1.o ./gea2.o ./gea3.o ./llc.o ./llc_entity.o ./llc_cfgparams.o ./bssgp.o ./bssgp_entity.o ./bssgp_cfgparams.o ./ns.o ./ns_entity.o ./ns_cfgparams.o ./nsvc_entity.o ./m3ua.o ./m3ua_entity.o ./m3ua_cfgparams.o ./m3ua_transport_entity.o ./ns_ip_entity.o ./gtpcv0.o ./gtpcv0_entity.o ./gtpcv0_cfgparams.o ./gtpcv1.o ./gtpcv1_entity.o ./gtpcv1_cfgparams.o ./gtpcv2.o ./gtpcv2_entity.o ./gtpcv2_cfgparams.o ./gtpu_entity.o ./gtpu.o ./gtpu_cfgparams.o ./ranap_entity.o ./ranap.o ./ranap_cfgparams.o ./S1apMsgs.o ./s1ap.o ./s1ap_entity.o ./s1ap_cfgparams.o ./sccp_entity.o ./sccp.o ./sccp_cfgparams.o ./mapss7.o ./mapss7_entity.o ./mapss7_cfgparams.o ./cap.o ./cap_entity.o ./cap_cfgparams.o ./tcap.o ./tcap_entity.o ./tcap_cfgparams.o ./diameter.o ./diameter_entity.o ./diameter_cfgparams.o ./radius.o ./radius_entity.o ./radius_cfgparams.o ./ikev2.o ./ikev2_entity.o ./ikev2_entity_responder.o ./ikev2_entity_informational.o ./ikev2_entity_child.o ./ikev2_cfgparams.o ./ikev2_payload.o ./ikev2_crypto.o ./aka.o ./ikev2_eap_common.o ./ikev2_eap_aka.o ./ikev2_eap_sim.o ./ipsec_data.o ./ipsec_data_cfgparams.o ./ipsec_data_entity.o ./ipse
> c_esp_entity.o ./sha1.o ./sha1-internal.o ./xfrm.o ./xfrm_entity.o ./xfrm_load_entity.o ./xfrm_cfgparams.o ./xfrm_message.o ./bssap.o ./bssap_entity.o ./bssap_cfgparams.o ./traffic.o ./tlv.o ./gx.o ./asn.o ./stargen.o ./eventbridge.o ./CliAttrib.o ./CliObject.o ./CliCommand.o ./CliObjectSyfer.o ./CliObjectSyferCard.o ./CliObjectEth.o  ./CliHandlerServer.o ./CliHandlerServerSyfer.o  ./libs/librohc.a ../../framework//cli/libs/glib-2.0.0/lib/libglib-2.0.a ./libs/libsnutils.a ./libs/libcommon.a ./libs/libasnbase.a ./libs/libs1apgen.a ./libs/libsctp.a ./libs/libpcap.a -L . -L ../syfer_ssl/openssl-0.9.8g/ -L../../framework//eventbridge -lssp -lsyfer_ssl -lcrypto -leventbridge -ldl -o flare
> ./libs/libpcap.a(nametoaddr.o): In function `pcap_nametoaddrinfo':
> nametoaddr.c:(.text+0xa3): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
> ./libs/libpcap.a(nametoaddr.o): In function `pcap_nametoaddr':
> nametoaddr.c:(.text+0x1a): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
> ./libs/libpcap.a(nametoaddr.o): In function `pcap_nametonetaddr':
> nametoaddr.c:(.text+0xdb): warning: Using 'getnetbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
> ./libs/libpcap.a(nametoaddr.o): In function `pcap_nametoproto':
> nametoaddr.c:(.text+0x2cb): warning: Using 'getprotobyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
> ./libs/libpcap.a(nametoaddr.o): In function `pcap_nametoport':
> nametoaddr.c:(.text+0x12f): warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

And of course these warnings indicate that your application is being 
linked statically, as Philippe suggested earlier.  Unless this is an 
embedded application, you generally won't want to link statically, and I 
wonder why it was done.

To run Valgrind, it will be simpler if you turn this off for debugging.  
If you aren't allowed to do make that kind of change to the Makefile 
structure even when debugging, you will need to follow the directions 
pointed out by Philippe (which I have never used; my applications are 
dynamically linked).

-- 
     David Chapman      dcc...@ac...
     Chapman Consulting -- San Jose, CA
     Software Development Done Right.
     www.chapman-consulting-sj.com