breakage on master.

I just committed some code changing how logging works so that the post-mortem dumping has a possibility of actually working. It looks a lot closer to how I want it to be, but it does seem to have a number of bugs right now which may take a couple days to nail down.

unless you're feeling brave, either stick with the 1.4 release, or 8127f706044297d92c7448a075be51dff73d747a which was the last 'known good' commit before last nights carnage.

I hope to be on top of things in a day or two.

Dave

The good news: That work is pretty much done. Next week I'll add the interesting parts to tainted_postmortem().
It's actually really handy to be able to do something like

	output(0, "%s\n", rec->prebuffer);

and get what would have been dumped to the screen/logs if you hadn't passed in -q or -l off.

The bad news: While working on this stuff the last few days I found a bunch of other bugs that I've also committed fixes/workarounds for. With that stuff out of the way, I'm seeing pretty regular corruption of the pid map. This *might* be the bugs that Michael reported last week has become easier to hit, or it might be that this weeks hacking has introduced some new damage.

So far I've not had luck tracking it down, so I've pushed out everything I had pending in the hopes someone else spots something obvious.

When it fails, it's interesting to note that the corrupted values in the pid map are nearly always the same. I see either -943208505 or 943208504. Which are 0xc7c7c7c7 and 0x38383838.

Which smells like something has called rand32() -> rept8 on a stale/wrong pointer somewhere, or we're walking past the end of a buffer. (though it's curious that that function would nearly always pick those values,
so maybe my guess is off).

Dave