ITS#3456 syncprov segfault

[hyc@symas.com]

OK, here is the situation - in FreeBSD the default thread stack size is 
1MB. (It used to be only 64K). In slapd we set the thread stack size to 
4MB, but that only takes effect for newly created threads. In this case, 
the execution is occurring on thread 0, the initial thread, and there 
does not appear to be any way to alter this thread's stack size.

On other platforms, thread 0 just uses the main process stack, which is 
controlled by limit/ulimit. On FreeBSD, thread 0 still gets only a 1MB 
stack regardless of the value the stack limit. Note that this behavior 
depends on whether or not a program is linked with -lpthread. A program 
that does not have -lpthread gets the stack size dictated by the stack 
limit. A program that does have -lpthread gets the 1MB thread stack, 
even in its main thread.

I don't know of any way to alter the stack size used by thread 0 on 
FreeBSD, you should ask on a FreeBSD developer's mailing list for more 
help here.

Dusty Doris wrote:
>>>  Did those print statements help make more sense of it?
>>>       
>> Well, they just seemed to show normal behavior, for the most part. At
>> this point I think the process stack is getting overwritten, that would
>> explain why the later portions of the stack trace aren't sensible. I'd
>> like to start slapd under gdb and set a few breakpoints to see if that's
>> really what is happening.
>>
>> Actually, come to think of it, you can check this yourself. What does
>> "ulimit -s" say on your system? For completeness' sake, what does
>> "ulimit -a" say?
>>
>> --
>>     
>
> # ulimit -a
> core file size        (blocks, -c) unlimited
> data seg size         (kbytes, -d) 524288
> file size             (blocks, -f) unlimited
> max locked memory     (kbytes, -l) unlimited
> max memory size       (kbytes, -m) unlimited
> open files                    (-n) 11095
> pipe size          (512 bytes, -p) 1
> stack size            (kbytes, -s) 65536
> cpu time             (seconds, -t) unlimited
> max user processes            (-u) 5547
> virtual memory        (kbytes, -v) unlimited
>
>
>
>   


-- 
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support