Re: test020 inconsistent with SLAPI (ITS#2787)

[ando@sys-net.it]

This is a multi-part message in MIME format.
--80D5F44F762685D214B77A7B47FD735B414C33D2
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hyc@symas.com wrote:

>There is already a backtrace; set the environment variable
>FNCCHK_MEMORY_STACK to the depth of the trace stack you want. I usually use
>4, but more may be helpful in some cases.
>
I might be missing something:

- I'm linking my binary with -lfnccheck;
- setting FNCCHK_MEMORY_STACK=4 FNCCHK_MEMORY=1
- running fncdump with -memory -memory-more -memory-stack-more -nm
but I still get one single place for events, e.g.

Block 36
   alloc, size: 0x8080ad0,7        strdup (strdup.c:45)
      freed at:                    rewrite_map_destroy (map.c:480)

when things are fine, or

Block 55
   alloc, size: 0x8080ba8,4        strdup (strdup.c:45)
      freed at:                    rewrite_map_destroy (map.c:480)
   unreferenced address (0x8080ba8) for 'realloc' at 
rewrite_subst_compile (subst.c:177)
   unreferenced address (0x8080bb8) for 'free' at rewrite_subst_destroy 
(subst.c:481)
   unreferenced address (0x8080bc8) for 'free' at rewrite_subst_destroy 
(subst.c:487)

My question is, without looking at the code, can I see a stack
trace of the call to strdup.c:45 ?  Moreover, all these "unreferenced
address" lags seem to be incorrect, and, at least, one line off.

I don't want to start a discussion or even debugging of fnccheck
here, though, because it might not be the most appropriate forum :)

Ando.

>
>  -- Howard Chu
>  Chief Architect, Symas Corp.       Director, Highland Sun
>  http://www.symas.com               http://highlandsun.com/hyc
>  Symas: Premier OpenSource Development and Support
>
>  
>
>>-----Original Message-----
>>From: Pierangelo Masarati [mailto:openldap-its@OpenLDAP.org]
>>Sent: Saturday, November 22, 2003 7:44 AM
>>To: hyc@OpenLDAP.org
>>Subject: Re: test020 inconsistent with SLAPI (ITS#2787)
>>
>>
>>librewrite internal test (libraries/librewrite/rewrite)
>>now ends with 0 leaks in all tested cases (fnccheck 1.5.1)
>>slapd ends with so many leaks that I'm unable to detect
>>those related to librewrite :)
>>
>>To improve leak detection capabilities in fnccheck, a
>>limited backtrace in memory allocation would be of help
>>(memory allocated in strdup.c:<lineno> is of little help :)
>>
>>Ando.
>>
>>    
>>
>
>
>  
>



--80D5F44F762685D214B77A7B47FD735B414C33D2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename=disclaimer.txt

+----------------------------------------------------------------------------+
|   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax:+390382476497    |
+----------------------------------------------------------------------------+
--80D5F44F762685D214B77A7B47FD735B414C33D2--