[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
back-sql/search.c.
Of course, if you continue with your fix, this will become redundant.
Ciao, p.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497