[Date Prev][Date Next]
Re: [JunkMail] Re: (ITS#3404) sockber stack SEGVs
>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
>========== ====== =========== =======================================
> 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
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
Symas: Premier OpenSource Development and Support