Michael Ströder wrote: > What does it mean when slapd aborts with this assertion? > > ------------------------------------ snip ------------------------------------ > slapd: attr.c:481: attr_merge: Assertion `( nvals == ((void *)0)&& > (*a)->a_nvals == (*a)->a_vals ) || ( nvals != ((void *)0)&& ( ( (*a)->a_vals > == ((void *)0)&& (*a)->a_nvals == ((void *)0) ) || ( (*a)->a_nvals != > (*a)->a_vals ) ) )' failed. > Aborted > ------------------------------------ snip ------------------------------------ > > In the source code there is a FIXME remark. Does that remark mean the > assertion is still not as strict as required or that the assertion might be > too strict? Maybe Ando remembers why he wrote FIXME there. Looking at the git log, the original commit was actually wrong. Ando fixed it later, perhaps he just forgot to remove the "FIXME" afterward.

On Fri, 16 Mar 2012 12:40:31 +0100, Michael Ströder wrote: > We saw this assertion in a production server during processing a modify of an > entry. My co-worker said he could reproduce it. Does it mean the BDB files > were corrupt? Maybe, in particular if you upgraded without doing slapcat/slapadd.

But a FIXME followed by an assert looks suspiciously like "Shouldn't happen, but who knows if it does" - which doesn't belong in production code. Can you provide a gdb 'backtrace full' which also does 'print **a'?

Michael Ströder wrote: > HI! > > What does it mean when slapd aborts with this assertion? > > ------------------------------------ snip > ------------------------------------ > slapd: attr.c:481: attr_merge: Assertion `( nvals == ((void *)0)&& > (*a)->a_nvals == (*a)->a_vals ) || ( nvals != ((void *)0)&& ( ( > (*a)->a_vals > == ((void *)0)&& (*a)->a_nvals == ((void *)0) ) || ( (*a)->a_nvals != > (*a)->a_vals ) ) )' failed. > Aborted > ------------------------------------ snip > ------------------------------------ > > In the source code there is a FIXME remark. Does that remark mean the > assertion is still not as strict as required or that the assertion > might be > too strict? Maybe Ando remembers why he wrote FIXME there. Looking at the git log, the original commit was actually wrong. Ando fixed it later, perhaps he just forgot to remove the "FIXME" afterward.