[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#3404) sockber stack SEGVs
The syncrepl provider can be considered as the most common trigger of the
slab memory allocator bug just because it is a long running one. Any such
thread could be hit as unstable because of it. With the new buddy slab
allocator, it is quite certain that the problem already does not exist. If
you're interested, it would be very helpful to try the new buddy allocator
together with the new syncrepl provider since it did yet go through serious
tests.
- Jong-Hyuk
----- Original Message -----
From: <hyc@symas.com>
To: <openldap-its@OpenLDAP.org>
Sent: Wednesday, December 08, 2004 12:04 PM
Subject: Re: (ITS#3404) sockber stack SEGVs
> Also I should note that I've rewritten the syncrepl provider in CVS
> HEAD. The new implementation will be part of OpenLDAP 2.3. The
> implementation for OpenLDAP 2.2 is being deleted from CVS HEAD. This is
> relevant because the syncrepl provider seemed to be the most common
> cause of triggering this bug. If you're interested, it would be good to
> give the new syncrepl provider code in HEAD some in-depth testing.
>
> Aaron Richton wrote:
>
> >>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
> >>
> >>
> >
> >I agree. I've been playing with this further on a syncrepl master
(2.2.19,
> >without Followup 3 patch) and found some:
> >
> ><rtc> Write to unallocated (wua) on thread 4:
> >Attempting to write 4 bytes at address 0x863ca4
> > which is 4 bytes past end of heap block of size 1048576 bytes at
0x763ca0
> >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 0xde1157b8
> >Location of error:
> >current thread: t@4
> >=>[1] ber_bvarray_add_x(a = 0xa733f7e0, bv = 0xa733f72c, ctx = 0x63c878),
line 785 in "memory.c"
> > [2] slap_build_syncUUID_set(0x63d2d8, 0xa733f7e0, 0x4b97d38,
0xa733f968, 0x0, 0x12e), at 0xd25b4
> > [3] hdb_do_search(op = 0x63d2d8, rs = 0xa73ffd58, sop = 0x63d2d8, ps_e
= (nil), ps_type = 0), line 1308 in "search.c"
> > [4] hdb_search(op = 0x63d2d8, rs = 0xa73ffd58), line 422 in "search.c"
> > [5] do_search(op = 0x63d2d8, rs = 0xa73ffd58), line 412 in "search.c"
> > [6] connection_operation(ctx = 0xa73ffe14, arg_v = 0x63d2d8), line 1079
in "connection.c"
> > [7] ldap_int_thread_pool_wrapper(xpool = 0x558bf8), line 467 in
"tpool.c"
> >
> ><rtc> Write to unallocated (wua) on thread 4:
> >Attempting to write 4 bytes at address 0x863ca0
> > which is just past heap block of size 1048576 bytes at 0x763ca0
> >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 0xde1157b8
> >Location of error:
> >current thread: t@4
> >=>[1] ber_bvarray_add_x(a = 0xa733f7e0, bv = 0xa733f72c, ctx = 0x63c878),
line 784 in "memory.c"
> > [2] slap_build_syncUUID_set(0x63d2d8, 0xa733f7e0, 0x4ba08c8,
0xa733f968, 0x0, 0x12e), at 0xd25b4
> > [3] hdb_do_search(op = 0x63d2d8, rs = 0xa73ffd58, sop = 0x63d2d8, ps_e
= (nil), ps_type = 0), line 1308 in "search.c"
> > [4] hdb_search(op = 0x63d2d8, rs = 0xa73ffd58), line 422 in "search.c"
> > [5] do_search(op = 0x63d2d8, rs = 0xa73ffd58), line 412 in "search.c"
> > [6] connection_operation(ctx = 0xa73ffe14, arg_v = 0x63d2d8), line 1079
in "connection.c"
> > [7] ldap_int_thread_pool_wrapper(xpool = 0x558bf8), line 467 in
"tpool.c"
> >
> >
> >
> >
> >
>
>
> --
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support
>
>
>
>