View mode: basic / threaded / horizontal-split · Log in · Help
March 24, 2012
Array ops give sharing violation under Windows 7 64 bit?
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?
March 24, 2012
Re: Array ops give sharing violation under Windows 7 64 bit?
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?
March 24, 2012
Re: Array ops give sharing violation under Windows 7 64 bit?
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.
March 24, 2012
Re: Array ops give sharing violation under Windows 7 64 bit?
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
March 24, 2012
Re: Array ops give sharing violation under Windows 7 64 bit?
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.
March 24, 2012
Re: Array ops give sharing violation under Windows 7 64 bit?
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.
March 24, 2012
Re: Array ops give sharing violation under Windows 7 64 bit?
"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.
March 24, 2012
Re: Array ops give sharing violation under Windows 7 64 bit?
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.
March 24, 2012
Re: Array ops give sharing violation under Windows 7 64 bit?
"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.
March 24, 2012
Re: Array ops give sharing violation under Windows 7 64 bit?
"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.
« First   ‹ Prev
1 2 3 4
Top | Discussion index | About this forum | D home