Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713

[jsynacek@redhat.com]

On 11/04/2012 05:33 PM, michael@stroeder.com wrote:
> Full_Name: 
> Version: RE24 8f66d7dbad977c9186e010a52f0183b5d532acc9
> OS: openSUSE 12.2 x86_64
> URL: 
> Submission from: (NULL) (79.227.185.139)
> 
> 
> I get a seg fault when adding group entries with some regex-constrained
> attributes. This is RE24 with the recent fixes for slapo-constraint. The
> constraint setup works with 2.4.31.
> 
> Strange thing is that the entry is added to the database. So it seems to me that
> the seg fault happens after that while checking constraints for what
> slapo-memberof does?
> 
> As often this is a complex customer setup. So it's not that easy to narrow down
> the config and strip aways private customer data in a full traceback. I will do
> if really necessary.
> 
> Maybe this gives a first hint where to look:
> 
> No symbol "info" in current context.
> (gdb) info threads
>   Id   Target Id         Frame 
>   8    Thread 0x7faed2024700 (LWP 25001) 0x00007faee54448f4 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   7    Thread 0x7faed1823700 (LWP 25002) 0x00007faee54448f4 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   6    Thread 0x7faed2825700 (LWP 25000) 0x00007faee54448f4 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   5    Thread 0x7faed8d6a700 (LWP 24999) 0x00007faee54448f4 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   4    Thread 0x7faedc62d700 (LWP 24998) 0x00007faee44ce8a3 in epoll_wait ()
> from /lib64/libc.so.6
>   3    Thread 0x7faee41d2700 (LWP 24995) 0x00007faee5441fef in pthread_join ()
> from /lib64/libpthread.so.0
>   2    Thread 0x7faed1022700 (LWP 25003) 0x00007faee54448f4 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> * 1    Thread 0x7faecbfff700 (LWP 25004) 0x00007faedfeccf89 in
> constraint_check_restrict (op=0x7faecbffdd80, c=0xf8c550, e=0x0) at
> constraint.c:713
> 

Hello Michael,

can you please provide a full backtrace of thread 1? A quick look suggest that
there's something wrong, because constraint_check_restrict probably should not
be called with e=0x0, but I'm unable to tell anything else with such restricted
information.

Also, if the problem is in my fix, it should be fairly easily reproducible with
just a few slapadds with the right data.

Cheers,

-- 
Jan Synacek
Software Engineer, BaseOS team Brno, Red Hat