It works when using constraint.c of OpenLDAP release 2.4.32.

It also works when using constraint.c of OpenLDAP release 2.4.33.

Maybe it's caused by fix for ITS#7418?

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

FYI: I sent output of bt full to Jan with some data stripped because of
privacy concerns.

Note that the entry for which constraint checking is done is added to the
database. So something might be wrong *after* the check.

Ciao, Michael.

On 11/08/2012 08:14 AM, michael@stroeder.com wrote:
> FYI: I sent output of bt full to Jan with some data stripped because of
> privacy concerns.
> 
> Note that the entry for which constraint checking is done is added to the
> database. So something might be wrong *after* the check.
> 
> Ciao, Michael.
> 
> 

Can you please try the attached patch? If it doesn't fix the issue (or breaks
something else that I'm not aware of) I will need a reproducer config and data.

Thank you,

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

Jan Synacek wrote:
> On 11/08/2012 08:14 AM, michael@stroeder.com wrote:
>> FYI: I sent output of bt full to Jan with some data stripped because of
>> privacy concerns.
>>
>> Note that the entry for which constraint checking is done is added to the
>> database. So something might be wrong *after* the check.
> 
> Can you please try the attached patch?

It seems to work. But I will test it during the next days more thoroughly.

Ciao, Michael.

Michael Ströder wrote:
> Jan Synacek wrote:
>> On 11/08/2012 08:14 AM, michael@stroeder.com wrote:
>>> FYI: I sent output of bt full to Jan with some data stripped because of
>>> privacy concerns.
>>>
>>> Note that the entry for which constraint checking is done is added to the
>>> database. So something might be wrong *after* the check.
>>
>> Can you please try the attached patch?
> 
> It seems to work. But I will test it during the next days more thoroughly.

No more seg faults so far in my setup which uses slapo-constraints quite
heavily. So I'd appreciate if Jan's patch lands in RE24 branch.

Ciao, Michael.

Michael Ströder wrote:
> Michael Ströder wrote:
>> Jan Synacek wrote:
>>> On 11/08/2012 08:14 AM, michael@stroeder.com wrote:
>>>> FYI: I sent output of bt full to Jan with some data stripped because of
>>>> privacy concerns.
>>>>
>>>> Note that the entry for which constraint checking is done is added to the
>>>> database. So something might be wrong *after* the check.
>>>
>>> Can you please try the attached patch?
>>
>> It seems to work. But I will test it during the next days more thoroughly.
> 
> No more seg faults so far in my setup which uses slapo-constraints quite
> heavily. So I'd appreciate if Jan's patch lands in RE24 branch.

What's the status of this?
Is a more formal submission of Jan's patch needed to get this in?

Ciao, Michael.

changed notes
changed state Open to Test
moved from Incoming to Software Bugs

changed notes
changed state Test to Release

changed notes
changed state Release to Closed

fixed in master
fixed in RE24