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

Re: (ITS#3456) test018 consumer segfault

hyc@symas.com wrote:

>I just realized what is going on - the syncprov overlay is searching for 
>the greatest entryCSN in the main process, before the thread subsystem 
>has started. So it is using the default process stack, not our large 
>thread stack. Setting a larger process stack with "ulimit -s" should fix 
>this issue. I wonder if we should rewrite the overlay to perform this 
>check using the runqueue instead, so that the check occurs in a thread. 
>Then we would need a way to prevent syncrepl searches from proceeding 
>until the check finished.
I had a related problem with back-sql when acting as a provider, where 
few calls to ch_free() wouldn't get the right context; I worked it 
around byusing a special hlper that checks the  
ldap_pvt_thread_pool_context() and, if it's NULL or different from the 
op->o_tmpmemctx,  uses the latter to explicitly free memory before it 
gets to the regular destroyer functions.  See backsql_entry_clean() in 

Of course, if you continue with your fix, this will become redundant.

Ciao, p.

    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497