savecore(8) increments /var/crash/bounds on each boot
Ed Maste
emaste at phaedrus.sandvine.ca
Wed Jun 15 03:49:42 GMT 2005
On Tue, Jun 14, 2005 at 07:24:24PM -0700, Doug White wrote:
> On Mon, 13 Jun 2005, Ed Maste wrote:
>
> > On Mon, Jun 13, 2005 at 01:03:50PM -0700, Doug White wrote:
> >
> > > On Mon, 13 Jun 2005, Ed Maste wrote:
> > >
> > > > I notice that as of sbin/savecore/savecore.c 1.72 and in 5.4-RELEASE
> > > > savecore increments the number in /var/crash/bounds on each boot,
> > > > regardless of whether it rebooted due to panic or was a clean shutdown.
> > > >
> > > > Is this the desired behaviour or an unintentional side effect?
> > > > We've been monitoring the value in bounds to detect panics, which
> > > > of course doesn't work anymore.
> > >
> > > Its certainly not the historical behavior :-)
> > >
> > > Think you could submit a patch with the fix?
> >
> > The attached patch does the trick. In -vv mode the bounds used to
> > be included with the first/last dump header output -- I just replaced
> > it with -1.
>
> I don't see how this works. It should generate a bunch of
> use-uninitialized warning since bounds is used in a sprintf at line 376,
> in DoFile():
>
> 376: sprintf(buf, "info.%d", bounds);
The patch I posted puts the getbounds() call back in the original location,
which is just before this sprintf -- no uninitialized use.
> plus additional sprintf's down the file, since the value of bounds is only
> set by that getbounds() call. The correct fix is to put a
>
> else
> goto done;
I don't see how that helps -- if bounds already contains a valid number
(the normal case) it will then skip over writing the new (incremented)
value back to the bounds file. Won't all cores get written to the same
file then?
--
Ed Maste, Sandvine Incorporated
More information about the freebsd-current
mailing list