Re: bugfixes

[Andrew J Berkley <berkley@wam.umd.edu>]

Kasper,

Welcome back!

The OM changes are significantly different now because of the new MP
scheme.  In fact, they are a lot simpler -- but they aren't written yet,
and I doubt that joev and I can hash out the changes yet, especially since
we're still conceptually floating (and the fact that I keep missing the
IRC meetings isn't helping  -- joev, are you available any time not during
the official times?).

So, I would suggest just freezing the code now to find the bugs in it.  I
kept ignoring all the segfaults, because I was using the test_net program
which works nicely (except when the page takes longer than 10 seconds to
load :).

After we have a working tree, then we can put in the MP and OM changes
(not that significant in terms of code changes, it is mainly conceptual).
I also need some time to work out the rest of the MP stuff, and that can
happen simultaneously with the debugging (I don't have to change the tree
to work this stuff out).

In terms of debugging, I would suggest working on replacing some of the
memory management stuff with things like a Buffer class for the filter
stacks, etc.  Things that will replace the old broken schemes instead of
fixing them.

>    4. Have a limited number of people do the bugfixing (most of it
>       is alloc/free and null point stuff), let's say 2 or 3. Wait with
>       all further changes until the code is reasonably free from
>       segfaults.

Why?  Maybe limit the actual people who can commit changes to the tree,
but no reason not to declare open season on bugs and have anyone hunt them
down and post results to mailing list :)

Andrew