Thread overview | |||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Xinok | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brad Roberts | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | "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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | "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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | "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. |
Copyright © 1999-2021 by the D Language Foundation