Hi all,

So, I've tracked down this bug and what is causing it; in accprocnt()
you'll find the following,


int

acctprocnt(void)

{

  struct stat     statacc;

  /*

  ** if accounting not supported, skip call

  */

  if (acctfd == -1)

    return 0;

  /*

  ** determine how many processes exited last interval

  */

  (void) fstat(acctfd, &statacc);

  if (acctsize > statacc.st_size) /* somebody did reset accounting? */

  {

    /*

    ** reposition to start of file

    */

    lseek(acctfd, 0, SEEK_SET);

    acctsize = 0;

  }

  return (statacc.st_size - acctsize) / acctrecsz;

}


As you can see the last line does a division, and this is the source of
the SIGFPE; when acctrecsz is zero obviously.

Now here comes the tricky bit as far as a bug fix is concerned;
acctrecsz is a static variable, i.e. a file local global variable.

And it gets worse, there are times when it might be used uninitialised,
or used after the accounting file is considered corrupt or otherwise
inaccessible (xref functions acctvers(), acctswon() (acctrecsz may not
be set after call to acctvers()) x3, and acctswon() acctrecsz may not be
set after call to acctvers() and return code of acctvers() is ignored.

So, the best way to fix this would require an extensive refactor and
re-write to fix these use of globals. This would mean using one struct
to encapsulate the accounting info (the accounting file fd, accounting
file version, account file record sizes, etc), and then allocate this
struct at runtime (in a suitable init function, quite possibly the one
that opens and initialises the accounting file), pass the accounting
file struct to functions that handle this accounting file data.

The other fix would be a quick and dirty fix to make sure that the
division never happens when acctrecsz is zero.

There could be a middle ground as well; but half hearted measures aren't
so appealing to me.

So I can write either, but which would you prefer? I'm guess the big
refactor / re-write would be harder to push upstream, but since I'm not
the maintainer I couldn't say.

Matt

Reply via email to