Re: assertion fault. on loggin

[Paul Edwards]

"Pierre" <pceteaudatmacif.fr@netcourrier.com> wrote in message 
b86193eb.0309120129.ac24ee3@posting.google.com">news:b86193eb.0309120129.ac24ee3@posting.google.com...
> > Ok.  Here's the latest test, I want to find out if 4 is still
> > working at the time that 3 is still working.
> And the result is...
>
> When fstat(4,&s) is call when fn is 3, it returns 0 and then still
> returns 0 when fn is 4 !
> I mean with your last test code, there is no more bug... !!

If only life was so simple.  :-)

> with this code :
>
> /* beginning of the new code */
> int fn;
> fn = fileno (bc->fp);
> if (fn == 3)
>  {
>   assert (fstat ( fn+1, &s ) != -1);
>  }
> /* return to the original code */
> assert (fstat ( fileno (bc->fp), &s ) != -1);
>
> No assert is raised !

I was under the impression that this problem was intermittent?
If it is intermittent, then I need you to keep running it until it
coredumps.

The normal sequence is:

1. this function is told to close 3.
2. this function is told to close 4.

Now I know that intermittently, (2) fails.

I now want to know at what stage (2) first reached failure.
So I am starting the inspection at point 1, and I'm going to
start moving forward.

> Is it possible to write this code in a cleaner way ? (I think fn==3
> may not be the good test every time, and the same with fn+1)

It is possible to do it, if that were the problem.  It is very unlikely,
but not impossible, that a *spurious* call to fstat(), is all that is
required to bypass the potential AIX bug in fstat().

On the offchance that that does work around the problem, and
you only want a workaround, rather than find the root cause,
then I'll give you some a "proper" kludge that most definitely
doesn't solve or find the underlying bug, but will avoid hardcoding
the 3 and "fn+1".

BFN.  Paul.