s4 provision with ol fails (bugzilla.samba 7040?)

[Endi Sukma Dewata]

Hi Kamen,

The patch seems to have fixed this particular problem. There are
still other problems which I will investigate, but I don't think
they are related to this. Thanks a lot!

--
Endi S. Dewata


----- "Kamen Mazdrashki" <kamen.mazdrashki at postpath.com> wrote:

> Hi Endi,
> 
> Attached patch should fix the problem you have encountered 
> (thanks a lot for that).
> I have implemented it wrong - I haven't noticed that 
> ildb_context is to be freed when a request is marked as 'done'.
> 
> Could you please try if that works for you?
> 
> -- 
> CU,
> Kamen Mazdrashki
> kamen.mazdrashki at postpath.com
> http://repo.or.cz/w/Samba/kamenim.git
> -------------------------------------
> CISCO SYSTEMS BULGARIA EOOD
> http://www.cisco.com/global/BG/
> 
> 
> > -----Original Message-----
> > From: samba-technical-bounces at lists.samba.org
> [mailto:samba-technical-
> > bounces at lists.samba.org] On Behalf Of Endi Sukma Dewata
> > Sent: Wednesday, March 03, 2010 2:03 AM
> > To: abartlet at samba.org
> > Cc: samba-technical at lists.samba.org
> > Subject: Re: s4 provision with ol fails (bugzilla.samba 7040?)
> > 
> > Andrew,
> > 
> > Here's the valgrind trace. As you can see the write on ldb_ildap.c
> > line 391 triggers the error. The earlier read & write on line 231
> > and 235 didn't cause any problem.
> > 
> > ==18041== Invalid write of size 1
> > ==18041==    at 0x4AF4536: ildb_callback (ldb_ildap.c:391)
> > ==18041==    by 0x4AF5B8B: ldap_match_message (ldap_client.c:177)
> > ==18041==    by 0x4AF5CB5: ldap_recv_handler (ldap_client.c:209)
> > ==18041==    by 0x4BB53E4: packet_recv (packet.c:414)
> > ==18041==    by 0x4AF5D1E: ldap_read_io_handler (ldap_client.c:221)
> > ==18041==    by 0x4AF5DA0: ldap_io_handler (ldap_client.c:237)
> > ==18041==    by 0x5022051: epoll_event_loop (tevent_standard.c:309)
> > ==18041==    by 0x50226E8: std_event_loop_once
> (tevent_standard.c:544)
> > ==18041==    by 0x501E750: _tevent_loop_once (tevent.c:497)
> > ==18041==    by 0x4AC5136: ldb_wait (ldb.c:578)
> > ==18041==    by 0x4ABF4C3: py_ldb_modify (pyldb.c:706)
> > ==18041==    by 0x568B059: PyCFunction_Call (methodobject.c:81)
> > ==18041==    by 0x56E7072: PyEval_EvalFrameEx (ceval.c:3706)
> > ==18041==    by 0x56E8E49: PyEval_EvalCodeEx (ceval.c:2968)
> > ==18041==    by 0x56E7297: PyEval_EvalFrameEx (ceval.c:3802)
> > ==18041==    by 0x56E8E49: PyEval_EvalCodeEx (ceval.c:2968)
> > ==18041==    by 0x56E7297: PyEval_EvalFrameEx (ceval.c:3802)
> > ==18041==    by 0x56E8E49: PyEval_EvalCodeEx (ceval.c:2968)
> > ==18041==    by 0x56E7297: PyEval_EvalFrameEx (ceval.c:3802)
> > ==18041==    by 0x56E8E49: PyEval_EvalCodeEx (ceval.c:2968)
> > ==18041==  Address 0xe553490 is 64 bytes inside a block of size 72
> > free'd
> > ==18041==    at 0x40057F6: free (vg_replace_malloc.c:325)
> > ==18041==    by 0x502445C: _talloc_free_internal (talloc.c:669)
> > ==18041==    by 0x502436B: _talloc_free_internal (talloc.c:631)
> > ==18041==    by 0x502436B: _talloc_free_internal (talloc.c:631)
> > ==18041==    by 0x502436B: _talloc_free_internal (talloc.c:631)
> > ==18041==    by 0x502436B: _talloc_free_internal (talloc.c:631)
> > ==18041==    by 0x502436B: _talloc_free_internal (talloc.c:631)
> > ==18041==    by 0x502436B: _talloc_free_internal (talloc.c:631)
> > ==18041==    by 0x502436B: _talloc_free_internal (talloc.c:631)
> > ==18041==    by 0x502436B: _talloc_free_internal (talloc.c:631)
> > ==18041==    by 0x502436B: _talloc_free_internal (talloc.c:631)
> > ==18041==    by 0x502436B: _talloc_free_internal (talloc.c:631)
> > ==18041==    by 0x502436B: _talloc_free_internal (talloc.c:631)
> > ==18041==    by 0x502436B: _talloc_free_internal (talloc.c:631)
> > ==18041==    by 0x502436B: _talloc_free_internal (talloc.c:631)
> > ==18041==    by 0x502436B: _talloc_free_internal (talloc.c:631)
> > ==18041==    by 0x502436B: _talloc_free_internal (talloc.c:631)
> > ==18041==    by 0x502436B: _talloc_free_internal (talloc.c:631)
> > ==18041==    by 0x502509E: _talloc_free (talloc.c:1133)
> > ==18041==    by 0x4AF0C62: extended_replace_dn
> > (extended_dn_store.c:138)
> > 
> > If I remove talloc_free() in extended_dn_store.c line 138 and rerun
> > valgrind the problem will still happen and the trace will point to
> > another talloc_free() on line 197. If I remove both of them the
> problem
> > will disappear. Thanks.
> > 
> > --
> > Endi S. Dewata
> > 
> > 
> > ----- "Andrew Bartlett" <abartlet at samba.org> wrote:
> > 
> > > On Tue, 2010-03-02 at 18:01 -0500, Endi Sukma Dewata wrote:
> > > > Andrew, Oliver,
> > > >
> > > > It seems like the in_ildb_callback field added in this
> revision:
> > > >
> > > >
> > > http://gitweb.samba.org/?p=samba.git;a=commitdiff;
> > h=80786148145e128c961a6f80a05585a17dfca63b
> > > >
> > > > was causing the problem. Valgrind indicates that it's trying to
> > > write
> > > > into a memory location was already freed by talloc_free() in
> > > > extended_dn_store.c line 138 and 197. If I remove those
> > > talloc_free()
> > > > the problem will disappear. Any idea? Thanks.
> > >
> > > Can you post the valgrind trace?  (So I can see what write is
> > > invalid).
> > >
> > > (BTW, well done in tracking this down)
> > >
> > > Thanks,
> > >
> > > Andrew Bartlett
> > > --
> > > Andrew Bartlett
> > > http://samba.org/~abartlet/
> > > Authentication Developer, Samba Team           http://samba.org
> > > Samba Developer, Cisco Inc.