Boost logo

Boost Testing :

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-11-07 09:13:15

Bronek Kozicki wrote:
>Reece Dunn <msclrhd_at_[hidden]> wrote:
> > Rene added a guard against this that terminates with the above error
> > message. I was unable to consistently reproduce the error and haven't
> > seen it for a while now and am still not sure exactly why the error
> > occurs.
> >
> > We could try and recover in this situation by waiting for a short
> > while, then retrying.
> >
> > NOTE: The problem file is execnt.c (see revision 1.14).
>Thanks for detailed info. I think I might be able to try to fix it on my
>computer and/or investigate further (locally)

No problem.

> > Bronek: what have you used to build bjam? Are you running through DOS
> > or CYGWIN?
>question 1 - it was many months ago and I do not remember, but according
>to dumpbin it was msvc71 (OPTIONAL HEADER VALUES 7.10 linker version)

Ok. That would seem to indicate that this is a problem with msvc binaries.

>question 2 - I run it from cmd.exe, which probably means for you DOS
>(although cmd.exe has nothing to do with DOS, except default prompt and
>choice of builtin commands).

That's what I meant :).

Hmmm. The files are being opend for a short space of time, but the temporary
files are being named based on the slot number. Q: Is this failing when the
slot number has cycled back *and* the temporary file still exists (but that
doesn't make sense, unless it hasn't been cleaned up)? This is the only
thing that I can think of for now.

If you can build a modified bjam, in execnt.c, where you have

       /* Write command to bat file. */
        f = fopen( cmdtab[ slot ].tempfile, "w" );
        if (!f)
            printf( "failed to write command file!\n" );
            exit( EXITBAD );
        fputs( string, f );
        fclose( f );

try inserting a fflush( f ); before the fclose and see if that fixes it
although I don't see why it would.

(By now you know I am guessing wildly ;))

- Reece

Boost-testing list run by mbergal at