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

Oliver Liebel oliver at itc.li
Wed Mar 3 00:53:31 MST 2010 

as endi said, there must be still other problems.
i have tried it with the patch from kamen, but provision still fails:

Traceback (most recent call last):
   File "setup/provision", line 245, in <module>
     nosync=opts.nosync,ldap_dryrun_mode=opts.ldap_dryrun_mode,useeadb=eadb)
   File "bin/python/samba/provision.py", line 1305, in provision
     dom_for_fun_level=dom_for_fun_level)
   File "bin/python/samba/provision.py", line 942, in setup_samdb
     samdb.add_ldif(schema.schema_data, controls=["relax:0"])
   File "bin/python/samba/__init__.py", line 258, in add_ldif
     self.add(msg,controls)
_ldb.LdbError: (3, 'error in module acl: Time limit exceeded (3)')
A transaction is still active in ldb context [0x944ecf0] on 
/usr/local/samba/private/secrets.ldb


greetings
oliver

Am 03.03.2010 02:20, schrieb 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.
>>>>          
>
>

More information about the samba-technical mailing list