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

Kamen Mazdrashki kamen.mazdrashki at postpath.com
Tue Mar 2 17:34:38 MST 2010


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-s4-ildap-fine-tune-ildb_callback.patch
Type: application/octet-stream
Size: 1148 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100303/1cd9cb4d/attachment.obj>


More information about the samba-technical mailing list