|
|
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