[Freeciv-Dev] Re: Valgrind

[Jason Dorje Short <jdorje@xxxxxxxxxxxx>]

Christian Knoke wrote:
> On Sat, Nov 20, 2004 at 09:43:59AM -0600, Mike Kaufman wrote:
>
> > On Sat, Nov 20, 2004 at 02:18:32PM +0100, Christian Knoke wrote:
> >
> > > Is the output of valgrind of any interest, and when?
> > it is of interest. when there are memory leaks that that we can fix, i.e.
> > not in libraries like libc or readline.
>
> Are there any options you can recommend for valgrind?
>
> Ok then, here are some snippets out of the error log, just tell me whether
> they are useful or not. I'll learn by try and error :)
>
> I got some of these:
>
> ==3772==  Address 0x1C4BF918 is 128 bytes inside a block of size 2048
> alloc'd
> ==3772==    at 0x1B905901: calloc (vg_replace_malloc.c:176)
> ==3772==    by 0x1BF6909C: XOpenDisplay (in /usr/X11R6/lib/libX11.so.6.2)
> ==3772==    by 0x1BC17FE1: gdk_display_open (gdkdisplay-x11.c:151)       
> ==3772==    by 0x1BBF7BA5: gdk_display_open_default_libgtk_only (gdk.c:403)
> ot this:
>
> ==3772==  Address 0x1CA480CB is 115 bytes inside a block of size 40960
> alloc'd
> ==3772==    at 0x1B904EDD: malloc (vg_replace_malloc.c:131)
> ==3772==    by 0x8098A06: fc_real_malloc (mem.c:79)        
> ==3772==    by 0x80A528B: new_socket_packet_buffer (connection.c:466)
> ==3772==    by 0x80A56A7: connection_common_init (connection.c:610)      
Many types of warnings have two pieces of data associated with them: the 
data about the warning itself, and for memory warnings data about where 
the memory the warning is in was allocated or deallocated.  Any time it 
says "Adress xxx is yyy bytes inside a block zzz" this is the memory 
information and it is useless without the actual error information itself.
Both of these give the memory information about a warning, but without 
the warning itself.  Both of these are probably semi-spurious "write 
contains uninitialized data" warnings however.  However the second one 
probably indicates uninitialized data written over the network which 
should be fixed if anyone can find it.
You can see here how the backtrace isn't long enough.  By default 
valgrind gives a backtrace of 4 lines, which isn't enough for library 
calls or even some glibc (malloc) calls.  Use --num-callers=50.
> These look interesting to me:
>
> ==3772== Use of uninitialised value of size 4
> ==3772==    at 0x80C7FCF: send_packet_player_attribute_chunk_100
> (packets_gen.c:11245)
> ==3772==    by 0x80AF267: send_attribute_block (packets.c:599)
> ==3772==    by 0x806AECF: attribute_flush (attribute.c:262)   
> ==3772==    by 0x806E441: send_turn_done (civclient.c:389)    
> ==3772== 
>
> ==3772== Conditional jump or move depends on uninitialised value(s)
> ==3772==    at 0x80C7FD1: send_packet_player_attribute_chunk_100   
> (packets_gen.c:11245)
> ==3772==    by 0x80AF267: send_attribute_block (packets.c:599)
> ==3772==    by 0x806AECF: attribute_flush (attribute.c:262)   
> ==3772==    by 0x806E441: send_turn_done (civclient.c:389)    
These are semi-real errors yes.  This is more data being sent over the 
network unitialized.  However I think because this is a delta packet 
this unitialization may actually cause a behavior change.
This is the kind of message that should be reported.  It probably 
doesn't cause any errors but it's hard to be sure.
> and then a lot of those:
>
> ==3772==  Address 0x1C578E14 is 60 bytes inside a block of size 120 free'd
> ==3772==    at 0x1B905460: free (vg_replace_malloc.c:153)
> ==3772==    by 0x1BE27527: (within /lib/libc-2.3.2.so)
> ==3772==    by 0x1BEE5E52: (within /lib/libc-2.3.2.so)   
> ==3772==    by 0x1BEE5E6E: (within /lib/libc-2.3.2.so)   
> ==3772== 
> ==3772== ERROR SUMMARY: 1358 errors from 22 contexts (suppressed: 85 from 1)
> ==3772== malloc/free: in use at exit: 4647556 bytes in 51139 blocks.        
> ==3772== malloc/free: 6300877 allocs, 6249738 frees, 470566294 bytes
This is again only data about the memory location of the error without 
information about the error itself.  However this is probably one of the 
many spurious library warnings that is given on exit.
jason