[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#4211) back-relay goes into infinte loop, causing segfault



> In testing setting up replicated cn=config, I've almost succeeded, except
> that
> back-relay is core dumping.

likely stack exaustion...

>  My configuration is:
>
> #######################################################################
> # back-relay database definitions
> #######################################################################
> database        relay
> suffix          cn=replica-config
> relay           cn=config massage
> updatedn
> "cn=replicator,cn=service,cn=applications,dc=stanford,dc=edu"
>
> #######################################################################
> # back-config database definitions
> #######################################################################
> database        config
> rootdn
> "cn=replicator,cn=service,cn=applications,dc=stanford,dc=edu"
> updatedn
> "cn=replicator,cn=service,cn=applications,dc=stanford,dc=edu"
>
>
>
> When I update this the master that replicates to this server using the id
> "cn=updater,cn=replica-config" to do the update on the master (slurpd uses
> cn=replicator...), is when back-relay core dumps.
>
> Here is the backtrace:
>
> 0x000dde90 in rwm_dn_massage_pretty_normalize (dc=0x5d800070, in=0xdae074,
> pdn=0x5d800088, ndn=0x5d800080) at rwmdn.c:124
> 124     rwmdn.c: No such file or directory.
>         in rwmdn.c
> (gdb) bt
> #0  0x000dde90 in rwm_dn_massage_pretty_normalize (dc=0x5d800070,
> in=0xdae074,
> pdn=0x5d800088, ndn=0x5d800080) at rwmdn.c:124
> #1  0x000db3d8 in rwm_op_dn_massage (op=0xdae060, rs=0x5dbffd58,
> cookie=0x113f20) at rwm.c:61
> #2  0x000dbcf4 in rwm_op_modify (op=0xdae060, rs=0x5dbffd58) at rwm.c:419
> #3  0x000775c0 in overlay_op_walk (op=0xdae060, rs=0x5dbffd58,
> which=32768,
> oi=0x2c9060, on=0x2c9158) at backover.c:482
> #4  0x0007769c in over_op_func (op=0xdae060, rs=0x5dbffd58,
> which=op_modify) at
> backover.c:542
> #5  0x0009db4c in relay_back_op_modify (op=0xdae060, rs=0x5dbffd58) at
> op.c:255
> #6  0x000775a8 in overlay_op_walk (op=0xdae060, rs=0x5dbffd58,
> which=32768,
> oi=0x162884, on=0x8000) at backover.c:490
> #7  0x0007769c in over_op_func (op=0xdae060, rs=0x5dbffd58,
> which=op_modify) at
> backover.c:542
> #8  0x0009db4c in relay_back_op_modify (op=0xdae060, rs=0x5dbffd58) at
> op.c:255
> #9  0x000775a8 in overlay_op_walk (op=0xdae060, rs=0x5dbffd58,
> which=32768,
> oi=0x162884, on=0x8000) at backover.c:490

The only reason I see for this exaustion is a misconfiguration of the
rewrite stuff; back-relay does its best to detect if the resolved database
is ... itself, but apparently the test is failing in this case.  I haven't
looked at the issue right now (I bet it's pretty easy to reproduce); I
suspect something different than usual is going on when the relayed
database is back-config...

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it



Ing. Pierangelo Masarati
Responsabile Open Solution

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
------------------------------------------