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