Matthias Scheler wrote:

> It's just an example based on experiences from working as operating
> system developer for several years. I've only seen problems hidden
> by debugging kernels for other reasons (e.g. different use of
> memory allocators).

Right. Race conditions, and I think also locking issues, are easily
hidden with changing timing by adding/removing code. I've seen it when
debugging a Systrace race condition about a year or two ago.

That said, I think you can't have a win-win situation, because while
some bugs will be hidden by enabling debugging options, others will be
revealed.

I'd like to see this discussion going towards thinking up a policy for
when NetBSD should enable/disable the debugging options, rather than
"they will always be turned on/off in all kernels during all stages of
development and users will have to rebuild to toggle".

Here's one, OTOH: Always enabled in -current; disabled when entering
first stages of release engineering to (*before* the tag), after the
tag, the branch will have it disabled, during the entire release
engineering process including the release; -current will have it enabled
again.

-e.