Re: [JunkMail] Re: (ITS#3404) sockber stack SEGVs

[hyc@symas.com]

richton@nbcs.rutgers.edu wrote:

>Overall testing results:
>
>Finally, the syncrepl provider seems stable. I haven't been running this
>long enough to make a formal declaration, but I believe this/ITS#3420 is
>the root cause of (my) ITS#3296, 3300, and possibly other submitters'
>syncrepl issues. I have not applied the patch to syncrepl consumers (if
>it's not broken, don't touch it...)
>  
>
OK. I'm going to leave those other ITS's untouched for now.

>Some technical notes from the debugger:
>
>The memory debugger I'm running in makes "Actual leaks" and "Possible
>leaks" reports. The size of the "Actual leaks" reported goes up
>dramatically when using the patch, from 1860 bytes to ~34k. Here's the
>report, although I'm not sure if there's anything to take from this:
>
>Actual leaks report (actual leaks: 1802  total size: 35646 bytes)
>
>  Total     Num of  Leaked     Allocation call stack
>  Size      Blocks  Block
>                    Address
>==========  ====== =========== =======================================
>      9312     581      -      ber_memalloc_x < ber_dupbv_x
>      9240     577      -      ber_memalloc_x < ber_memalloc
>
>  
>
This is probably significant, and needs to be tracked down. The call 
stack above doesn't go back far enough, can you set it to do a longer trace?

>ITS#3420 patch traded the uninitalized write for an uninitalized read.
>This also doesn't seem nearly as important, but I again include the trace
>for completeness:
>  
>
This is again due to padding at the end of the sl_malloc'd blocks, and 
can be safely ignored.

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support