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?
Ciao, Michael.
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.
Howard Chu wrote:
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.
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?
Ciao, Michael.
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'?
Hallvard B Furuseth wrote:
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.
Upgraded what? slapd? Was there a change in BDB format from 2.4.29 to 2.4.30?
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'?
Unfortunately I'm currently not in charge actively maintaining this system.
In the meantime my co-worker fixed it by doing slapcat/slapadd. So I guess the DB was indeed corrupt.
My question was about the state of the assertion and whether the interpretation (and as a consequence the slapcat/slapadd-operation) was correct.
Ciao, Michael.
Michael Ströder wrote:
Upgraded what? slapd? Was there a change in BDB format from 2.4.29 to 2.4.30?
No.
My question was about the state of the assertion and whether the interpretation (and as a consequence the slapcat/slapadd-operation) was correct.
Howard says schema change can be one reason. Always slapcat/slapadd when tweaking existing schema elements. In this case if one version of the attribute got a normaliser and the other did not.
Of course the various standards say existing schemas should never change, but keeping them frozen is sometimes easier said than done.
I mentioned upgrade because incompatible changes sometimes slip through, typically in a bugfix where the code doesn't stay backwards bug-compatible. So I always slapcat/slapadd when upgrading too, just in case.
On 03/16/2012 11:51 AM, Howard Chu wrote:
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.
I do not :), sorry. However, as far as I can recall, this was related to making sure that attributes without normalizer were treated consistently. It *should* always happen when handled by the frontend or the main backends, but occasionally, when that assert was added, there were overlays and other modules that did not, possibly because poorly maintained. For example, for quite some time seldom used pieces of code kept popping up which did not update a_numvals way after it was introduced.
Cheers, p.
-
Hallvard B Furuseth -
Howard Chu -
Michael Ströder -
Pierangelo Masarati