Re: Why did INVARIANTS hide the geom bug?
Dag-Erling Smørgrav wrote: walt <[EMAIL PROTECTED]> writes: ... Looking thru sys/geom I don't see any such ifdefs in your code, so I still don't know why the recent geom bug was hidden by INVARIANTS. On the contrary, there is a lot on INVARIANTS-specific code in GEOM: [EMAIL PROTECTED] /sys/geom% grep -r KASSERT . | wc -l 120 Thanks. That was a good explanation in only one line of code ;0) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why did INVARIANTS hide the geom bug?
walt <[EMAIL PROTECTED]> writes: > Looking at the code thru my amateur eyes it appears that > defining INVARIANTS allows the programmer to add whatever > code he wishes with an ifdef statement. That covers a > lot of territory. Looking thru sys/geom I don't see any > such ifdefs in your code, so I still don't know why the > recent geom bug was hidden by INVARIANTS. On the contrary, there is a lot on INVARIANTS-specific code in GEOM: [EMAIL PROTECTED] /sys/geom% grep -r KASSERT . | wc -l 120 DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why did INVARIANTS hide the geom bug?
Poul-Henning Kamp wrote: In message <[EMAIL PROTECTED]>, walt writes: If inclusion of INVARIANTS serves to disguise bugs in the kernel, I wonder if kernel committers should be using this option routinely? Please check into our current reality :-) Hm. How do I parse that sentence? If you are implying (as it says in NOTES) that INVARIANTS are "not enabled by default" then my question is certainly a stupid one. However, when I look at the GENERIC kernel config file I see options INVARIANTS options INVARIANT_SUPPORT so what am I to think? Do most kernel committers run a GENERIC kernel as the FBSD website says? Does anyone take a poll occasionally? Did I miss your point entirely? Suggest you check what INVARIANTS actually do. Looking at the code thru my amateur eyes it appears that defining INVARIANTS allows the programmer to add whatever code he wishes with an ifdef statement. That covers a lot of territory. Looking thru sys/geom I don't see any such ifdefs in your code, so I still don't know why the recent geom bug was hidden by INVARIANTS. Hope you're feeling better :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why did INVARIANTS hide the geom bug?
In message <[EMAIL PROTECTED]>, walt writes: >If inclusion of INVARIANTS serves to disguise bugs in >the kernel, I wonder if kernel committers should be >using this option routinely? Please check into our current reality :-) Suggest you check what INVARIANTS actually do. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why did INVARIANTS hide the geom bug?
walt <[EMAIL PROTECTED]> writes: > If inclusion of INVARIANTS serves to disguise bugs in > the kernel, I wonder if kernel committers should be > using this option routinely? It doesn't "serve to disguise bugs"; quite to the contrary, it serves to expose bugs and reveal their causes. However, INVARIANTS is slightly invasive; it adds code to the kernel, and in some cases changes data structures a little, and these changes have subtle side effects which may cause a bug to go into hiding. Such bugs are called "heisenbugs" (because the presence of the observer affects the outcome of the experiment...) and are generally caused by using a stack variable before its initialization, or dereferencing a pointer after freeing the memory it points to, etc. I recently fixed a bug in pkg_delete which had gone undetected for years because it depended on whether the stack had been used before the function the bug was in got called, and even if it had the garbage on the stack would in most cases be recognized as an incorrect value and ignored, but once in a while pkg_delete thought it was a valid file name and ended up doing the weirdest things. Running pkg_delete with kernel tracing enabled (which would have shown me exactly what pkg_delete was trying to do) caused the bug to magically disappear - I never quite figured out why - so I had a hell of a time tracking it down. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Why did INVARIANTS hide the geom bug?
If inclusion of INVARIANTS serves to disguise bugs in the kernel, I wonder if kernel committers should be using this option routinely? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
