Re: (ITS#4638) syncrepl and rwm overlay crash

[ando@sys-net.it]

nick@sqrt.co.uk wrote:
> Full_Name: Nick Burrett
> Version: 2.3.24
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/syncrepl-rwm.patch
> Submission from: (NULL) (216.239.33.25)
>
>
> When using sync-replication, and applying the rwm overlay configuration, we
> receive this crash on the client:
>
> RWM config:
>
> overlay rwm
> rwm-map attribute userPassword otherPassword
>
> Just start syncronising a client with an empty database from the master server
> to duplicate.
>
>
> [rw] searchDN: "dc=company,dc=com" -> "dc=company,dc=com"
> [rw] searchFilter: "(entryUUID=r\AB0:\0CC\10\28\8E\95\9D\F0{\D6l\C4)" ->
> "(entryUUID=r\AB0:\0CC\10\28\8E\95\9D\F0{\D6l\C4)"
> str2filter "(entryUUID=r\AB0:\0CC\10\28\8E\95\9D\F0{\D6l\C4)"
> put_filter: "(entryUUID=r\AB0:\0CC\10\28\8E\95\9D\F0{\D6l\C4)"
> put_filter: simple
> put_simple_filter: "entryUUID=r\AB0:\0CC\10\28\8E\95\9D\F0{\D6l\C4"
> begin get_filter
> EQUALITY
> ber_scanf fmt ({mm}) ber:
> ber_dump: buf=0x08324e90 ptr=0x08324e90 end=0x08324eaf len=31
>   0000:  a3 1d 04 09 65 6e 74 72  79 55 55 49 44 04 10 72   ....entryUUID..r
>   0010:  ab 30 3a 0c 43 10 28 8e  95 9d f0 7b d6 6c c4      .0:.C.(....{.l.
> get_ava: illegal value for attributeType entryUUID
> end get_filter 0
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1768571984 (LWP 5963)]
> 0xb7ccfc5c in _int_free () from /lib/tls/i686/cmov/libc.so.6
> (gdb) bt
> #0  0xb7ccfc5c in _int_free () from /lib/tls/i686/cmov/libc.so.6
> #1  0xb7ccec83 in free () from /lib/tls/i686/cmov/libc.so.6
> #2  0x0814dd31 in ber_memfree_x (p=0x10040101, ctx=0x8337aff) at memory.c:149
> #3  0x0807809f in ch_free (ptr=0x8337b07) at ch_malloc.c:139
> #4  0x08079393 in ava_free (op=0x9695b5e0, ava=0x9695b270, freeit=1) at
> ava.c:50
> #5  0x08063be1 in filter_free_x (op=0x9695b5e0, f=0x9695b280) at filter.c:491
> #6  0x0810ce67 in rwm_op_search (op=0x9695b5e0, rs=0x9695b350) at rwm.c:716
> #7  0x080b251e in overlay_op_walk (op=0x9695b5e0, rs=0x9695b350,
> which=op_search, oi=0x18377bff, on=0x82261c0) at backover.c:491
> #8  0x080b26ae in over_op_func (op=0x9695b5e0, rs=0x18377bff, which=406289407)
> at backover.c:551
> #9  0x080b2736 in over_op_search (op=0x18377bff, rs=0x18377bff) at
> backover.c:573
> #10 0x080ac731 in syncrepl_entry (si=0x82236e0, op=0x9695b5e0, entry=0x8322bd8,
> modlist=0x9695b420, syncstate=1,
>     syncUUID=0x9695b438, syncCookie_req=0x9695b450, syncCSN=0x9695b470) at
> syncrepl.c:1713
> #11 0x080a9aeb in do_syncrep2 (op=0x9695b5e0, si=0x82236e0) at syncrepl.c:727
> #12 0x080aac2c in do_syncrepl (ctx=0x18377bff, arg=0x8223900) at
> syncrepl.c:1086
> #13 0x0812bcfe in ldap_int_thread_pool_wrapper (xpool=0x82006c8) at tpool.c:478
> #14 0xb7d91ae0 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
> #15 0xb7d31c9a in clone () from /lib/tls/i686/cmov/libc.so.6
> (gdb)
>
>
> The crash occurs because syncrepl_entry is creating the
> Filter/AttributeAssertion structure on the stack and RWM is assuming that this
> was created with a malloc function.
>
> See patch syncrepl-rwm.patch for a solution (patch against current CVS).
>   

I see your point, but:

1) I don't think this is a hot problem, as using rwm with syncrepl seems 
to be a poor choice.  Syncrepl is designed to create shadows of existing 
data, while rwm is designed to muck with "incorrect" data.  A better 
suited solution would be to put a back-relay on the producer to 
"produce" the mucked data, and then shadow it.  Back-relay may not will 
to cooperate with syncrepl right now, but fixing it would likely be a 
much better solution than stacking rwm on top of a syncrepl consumer.

2) the bug actually is in slapo-rwm, which assumes all operation-related 
data can be freed at will.  It should rather replace it with its own, 
and restore things like they were by way of the sc_cleanup() callback.  
The reason it works like it does is that at the time slapo-rwm was 
designed, sc_cleanup() was not available yet.

slapo-rwm needs to be redesigned for a number of reasons; your issue 
would disappear after this redesign.  I'll consider this ITS a further 
solicitation for redesign, but I'd suggest to reject the patches (you 
may safely use them if you need to, but the final design will likely 
differ).

Cheers, p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office:   +39.02.23998309
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it
------------------------------------------