Chasing a memory leak

[Rich Fought]

Thanks, you are absolutely right.  There is an offset between the 
function addresses defined in the link map and the addresses that show 
up in gdb.  I've rolled up my Jump to Conclusions mat.

Rich

Simon Marlow wrote:
> Rich Fought wrote:
>> I'm getting into the weeds of a GHC-compiled program, and need a 
>> little help.  I'm trying to chase down a memory leak and Valgrind 
>> gives me the following:
>>
>> ==24390== 54,844 bytes in 639 blocks are definitely lost in loss 
>> record 69 of 69
>> ==24390==    at 0x400446D: malloc (vg_replace_malloc.c:149)
>> ==24390==    by 0x826337E: (within myprog)
>>
>>  From the link map of my program this address is in the function
>>
>> GHCziBase_zdszddmmin_info
>
> It's unlikely this is right.  This symbol is the code for the function 
> GHC.Base.$s$dmin, which is a specialised version ($s) of the default 
> method ($d) for min, in class Ord.  I very much doubt that min calls 
> malloc()!
>
> So it probably means that there are some symbols missing in your 
> program binary.  Try asking gdb what lies at that address, maybe?
>
> Cheers,
>     Simon
>
>
>