I've been upgrading to a Windows 64 bit box. Running the D test suite, I ran into a very strange problem. Here's the program:

---------------------------
 extern(C) int printf(const char*, ...);

 int main()
 {
     byte[3] a;
     byte[3] b;
     byte[3] c;

     a[] = b[] + c[];

     printf("Success\n");
     return 0;
 }
---------------------------

I run it from a cc.bat file that has the contents:

--------------------------
 ..\dmd test
 test
 ..\dmd test
--------------------------

and the result is:
--------------------------
 C:\test>..\dmd test

 C:\test>test
 Success

 C:\test>..\dmd test
 GetLastError = 32 test.exe
 OPTLINK (R) for Win32  Release 8.00.12
 Copyright (C) Digital Mars 1989-2010  All rights reserved.
 http://www.digitalmars.com/ctg/optlink.html
 OPTLINK : Error 3: Cannot Create File test.exe
 --- errorlevel 1
---------------------------

Note the failure to write out test.exe. I instrumented Optlink to figure out why, and the CreateFile() returns error 32, which is "The process cannot access the file because it is being used by another process."
If you run the commands by typing them in (not via a .bat file) it works. If the array
operations are removed, it works. It works on Windows XP.

I'm mystified. Does anyone have any ideas?

On 3/24/2012 11:55 AM, Walter Bright wrote:
> I'm mystified. Does anyone have any ideas?

If I add a del test.exe to the cc.bat file:
--------------------
..\dmd test
test
del test.exe
..\dmd test
-------------------

It now fails with GetLastError() of 5, meaning "Access is denied."

The cc.bat file has to be executed repeatedly for this to happen.

I wonder if it may have something to do with the operating system delayed writes?

On Saturday, 24 March 2012 at 19:08:00 UTC, Walter Bright wrote:
> On 3/24/2012 11:55 AM, Walter Bright wrote:
>> I'm mystified. Does anyone have any ideas?
>
> If I add a del test.exe to the cc.bat file:
> --------------------
> ..\dmd test
> test
> del test.exe
> ..\dmd test
> -------------------
>
> It now fails with GetLastError() of 5, meaning "Access is denied."
>
> The cc.bat file has to be executed repeatedly for this to happen.
>
> I wonder if it may have something to do with the operating system delayed writes?

If you have an antivirus, try disabling it before compiling.

On 3/24/2012 12:07 PM, Walter Bright wrote:
> On 3/24/2012 11:55 AM, Walter Bright wrote:
>> I'm mystified. Does anyone have any ideas?
> 
> If I add a del test.exe to the cc.bat file:
> --------------------
> ..\dmd test
> test
> del test.exe
> ..\dmd test
> -------------------
> 
> It now fails with GetLastError() of 5, meaning "Access is denied."
> 
> The cc.bat file has to be executed repeatedly for this to happen.
> 
> I wonder if it may have something to do with the operating system delayed writes?

I saw this sort of behavior in the auto-tester (was win7 at the time, now it's running on a windows server 2008 box) during the various combinations of compilation options until I switched to adding a counter and a suffix to each compilation output.  I don't recall there being a particular pattern to the failures (like being tied to array ops).

Later,
Brad

On 3/24/2012 12:18 PM, Xinok wrote:
> If you have an antivirus, try disabling it before compiling.

I have a brand new vanilla install of Windows 7 home premium.

On 3/24/2012 12:19 PM, Brad Roberts wrote:
> I saw this sort of behavior in the auto-tester (was win7 at the time,

At least I'm not losing my mind :-)

> now it's running on a windows server 2008 box)
> during the various combinations of compilation options until I switched to adding a counter and a suffix to each
> compilation output.  I don't recall there being a particular pattern to the failures (like being tied to array ops).

More investigation: If I delete the array ops, but add the import:

  import core.cpuid;

it fails. I'm also running a 6 core AMD FX 6100 CPU.

"Walter Bright" <newshound2@digitalmars.com> wrote in message news:jkl5ab$1ocp$1@digitalmars.com...
> I've been upgrading to a Windows 64 bit box. Running the D test suite, I ran into a very strange problem. Here's the program:
>
> ---------------------------
>  extern(C) int printf(const char*, ...);
>
>  int main()
>  {
>      byte[3] a;
>      byte[3] b;
>      byte[3] c;
>
>      a[] = b[] + c[];
>
>      printf("Success\n");
>      return 0;
>  }
> ---------------------------
>
> I run it from a cc.bat file that has the contents:
>
> --------------------------
>  ..\dmd test
>  test
>  ..\dmd test
> --------------------------
>
> and the result is:
> --------------------------
>  C:\test>..\dmd test
>
>  C:\test>test
>  Success
>
>  C:\test>..\dmd test
>  GetLastError = 32 test.exe
>  OPTLINK (R) for Win32  Release 8.00.12
>  Copyright (C) Digital Mars 1989-2010  All rights reserved.
>  http://www.digitalmars.com/ctg/optlink.html
>  OPTLINK : Error 3: Cannot Create File test.exe
>  --- errorlevel 1
> ---------------------------
>
> Note the failure to write out test.exe. I instrumented Optlink to figure
> out why, and the CreateFile() returns error 32, which is "The process
> cannot access the file because it is being used by another process."
> If you run the commands by typing them in (not via a .bat file) it works.
> If the array
> operations are removed, it works. It works on Windows XP.
>
> I'm mystified. Does anyone have any ideas?
>

Windows is known to enjoy holding locks on files just for the fuck of it. See if the behavior changes if you add some delay just before the last line. Or, if you adjust it so that compiling test.d takes longer.

On 3/24/2012 12:31 PM, Nick Sabalausky wrote:
> Windows is known to enjoy holding locks on files just for the fuck of it.
> See if the behavior changes if you add some delay just before the last line.
> Or, if you adjust it so that compiling test.d takes longer.

I tried those. No dice.

"Nick Sabalausky" <a@a.a> wrote in message news:jkl7fd$1rqs$1@digitalmars.com...
>
> Windows is known to enjoy holding locks on files just for the fuck of it. See if the behavior changes if you add some delay just before the last line. Or, if you adjust it so that compiling test.d takes longer.
>

If it still fails with the delay, you can probably find out (for whatever help it might be) what process is holding the file open by adding a pause right after running "test". Then before "Press[ing] a key" as it suggests, run SysInternal's Process Explorer to see who has the file open. My guess would be some basic Windows system process, but who knows.

"Nick Sabalausky" <a@a.a> wrote in message news:jkl816$1t08$1@digitalmars.com...
> "Nick Sabalausky" <a@a.a> wrote in message news:jkl7fd$1rqs$1@digitalmars.com...
>>
>> Windows is known to enjoy holding locks on files just for the fuck of it. See if the behavior changes if you add some delay just before the last line. Or, if you adjust it so that compiling test.d takes longer.
>>
>
> If it still fails with the delay, you can probably find out (for whatever help it might be) what process is holding the file open by adding a pause right after running "test". Then before "Press[ing] a key" as it suggests, run SysInternal's Process Explorer to see who has the file open. My guess would be some basic Windows system process, but who knows.
>

Acutally, my guess would be 'explorer.exe', that's the one that's really known for hogging files. Not sure know much knowing that would help though. But if it's *not* that, and is something unexpected, then maybe it would provide a clue.