Re: (ITS#3404) sockber stack SEGVs

[hyc@symas.com]

richton@nbcs.rutgers.edu wrote:

>>RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/controls.c,v
>>retrieving revision 1.72.2.20
>>    
>>
>
>Thanks for the patch; unfortunately, I'm still able to reproduce the above
>trace (eg followup 2) with it applied. For completeness, I note that there
>are some rui warnings on "from" (daemon.c:1612, 1665, 1721), then this one:
>  
>
"from" is initialized by the accept() system call. If there are any 
uninitialized fields there after that call, then your C library is broken.

><rtc> Read from uninitialized (rui) on thread 3:
>Attempting to read 1 byte at address 0x63f034
>    which is 532 bytes into a heap block of size 1048576 bytes at 0x63ee20
>This block was allocated from:
>        [1] ber_memalloc_x() at line 232 in "memory.c"
>        [2] ch_malloc() at 0x7fe38
>        [3] sl_mem_create() at line 82 in "sl_malloc.c"
>        [4] connection_operation() at line 1030 in "connection.c"
>        [5] ldap_int_thread_pool_wrapper() at line 467 in "tpool.c"
>        [6] _lwp_start() at 0xde1157b4
>Location of error:
>current thread: t@3
>=>[1] sl_realloc(ptr = 0x63f02c, size = 16U, ctx = 0x61f2b0), line 206 in "sl_malloc.c"
>  [2] get_ctrls(0x624248, 0xa7bffd58, 0x1, 0xa7bffcc8, 0x0, 0x624280), at 0x95c64
>  [3] do_search(op = 0x624248, rs = 0xa7bffd58), line 196 in "search.c"
>  [4] connection_operation(ctx = 0xa7bffe14, arg_v = 0x624248), line 1079 in "connection.c"
>  [5] ldap_int_thread_pool_wrapper(xpool = 0x558d20), line 467 in "tpool.c"
>  
>
This is harmless, an artifact of the original allocation being rounded 
up to a pad size and the padding being untouched.

>Finally, one in parseLDAPsync (now controls.c:1397 with the four-line patch)
>that is substantially similar to followup #2.
>
>
>
>On a related topic, when I stress tested overnight, there was a warning
>(of the same flavor) on
>   [3] parseLDAPsync(op = 0x629ba0, rs = -1514144424, ctrl = 62014932), line 1414 in "controls.c"
>
>unpatched line numbers, eg fmt = "o". I haven't yet reproduced this with
>the patch, but even without the patch it took a substantial amount of time
>for this to appear.
>
>
>  
>
It's not clear to me that these are significant either. It would be more 
interesting at this point to know of any wild writes going to invalid 
memory locations. Something like ElectricFence can help detect that, not 
sure if your memory debugger does or not.

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