CreateFileA issue

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

CreateFileA issue

Steve A
Hi,
We cross compile our project for win32 and win64.
But we have a bug on some platforms - well most.
We do a fast file open and read inited with CreateFileA
FILE_FLAG_SEQUENTIAL_SCAN.
It works great compiled on our old fed14 system.
File reads about 4 or 5 times faster than otherwise.

m_file = CreateFileA(
                                        filename,
                                        GENERIC_READ,
                                        0,
                                        0,
                                        OPEN_EXISTING,
                                        FILE_FLAG_SEQUENTIAL_SCAN |
FILE_ATTRIBUTE_READONLY | FILE_ATTRIBUTE_TEMPORARY,
                                        0);

but CreateFileA is failing for us at runtime when compiled on many
other systems. eg mint17 64 bit (and mint15 32 bit) for win32,
and also my mate's system for win64. We can sucessfully open files
conventionally on these systems though.

  mint17 64 bit:
binutils-mingw-w64-i686  2.23.52.20130620-1ubuntu1+3build1
g++-mingw-w64-i686   4.8.2-10ubuntu2+12
gcc-mingw-w64-base  4.8.2-10ubuntu2+12
gcc-mingw-w64-i686   4.8.2-10ubuntu2+12
mingw-w64-common     3.1.0-1
mingw-w64-i686-dev     3.1.0-1

  But it works when compiled on fed14 amd64 (for win32)
mingw32-pthreads-2.8.0-10.fc13.noarch
mingw32-runtime-3.15.2-5.fc13.noarch
mingw32-w32api-3.14-1.fc14.noarch
mingetty-1.08-4.fc12.x86_64
mingw32-filesystem-64-2.fc14.noarch
mingw32-gcc-4.5.0-1.fc14.x86_64
mingw32-binutils-2.20.1-2.fc14.x86_64
mingw32-cpp-4.5.0-1.fc14.x86_64
mingw32-gcc-c++-4.5.0-1.fc14.x86_64

I've done header comparisons for CreateFileA and the flags
but am stumped where the problem may be.

Any ideas ?
thanks, Steven

scidvspc.sf.net , Makefile.mingwx, src/win_mmap.h

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: CreateFileA issue

Eli Zaretskii
> Date: Sat, 2 Jan 2016 16:48:12 +1000
> From: Steve A <[hidden email]>
>
> We cross compile our project for win32 and win64.
> But we have a bug on some platforms - well most.
> We do a fast file open and read inited with CreateFileA
> FILE_FLAG_SEQUENTIAL_SCAN.
> It works great compiled on our old fed14 system.
> File reads about 4 or 5 times faster than otherwise.
>
> m_file = CreateFileA(
>                                         filename,
>                                         GENERIC_READ,
>                                         0,
>                                         0,
>                                         OPEN_EXISTING,
>                                         FILE_FLAG_SEQUENTIAL_SCAN |
> FILE_ATTRIBUTE_READONLY | FILE_ATTRIBUTE_TEMPORARY,
>                                         0);
>
> but CreateFileA is failing for us at runtime when compiled on many
> other systems.

Failing how?  Is there an error code when it fails returned by
GetLastError?  If so, what is the code?

>   mint17 64 bit:
> binutils-mingw-w64-i686  2.23.52.20130620-1ubuntu1+3build1
> g++-mingw-w64-i686   4.8.2-10ubuntu2+12
> gcc-mingw-w64-base  4.8.2-10ubuntu2+12
> gcc-mingw-w64-i686   4.8.2-10ubuntu2+12
> mingw-w64-common     3.1.0-1
> mingw-w64-i686-dev     3.1.0-1
>
>   But it works when compiled on fed14 amd64 (for win32)
> mingw32-pthreads-2.8.0-10.fc13.noarch
> mingw32-runtime-3.15.2-5.fc13.noarch
> mingw32-w32api-3.14-1.fc14.noarch
> mingetty-1.08-4.fc12.x86_64
> mingw32-filesystem-64-2.fc14.noarch
> mingw32-gcc-4.5.0-1.fc14.x86_64
> mingw32-binutils-2.20.1-2.fc14.x86_64
> mingw32-cpp-4.5.0-1.fc14.x86_64
> mingw32-gcc-c++-4.5.0-1.fc14.x86_64

These versions seem to be old, in both cases.  Not sure if that's
related.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: CreateFileA issue

Steve A
Thanks.
If i can figure out how to see GetLastError()
i will let you know, but stdout is missing of course
and our custom wish does not have a "console".
I think i should be able to, but I am more a wish programmer than C.
(The CreateFileA code in question is contributed.)
At the moment CreateFileA just returns INVALID_HANDLE_VALUE

On Sat, Jan 2, 2016 at 6:52 PM, Eli Zaretskii <[hidden email]> wrote:

>> Date: Sat, 2 Jan 2016 16:48:12 +1000
>> From: Steve A <[hidden email]>
>>
>> We cross compile our project for win32 and win64.
>> But we have a bug on some platforms - well most.
>> We do a fast file open and read inited with CreateFileA
>> FILE_FLAG_SEQUENTIAL_SCAN.
>> It works great compiled on our old fed14 system.
>> File reads about 4 or 5 times faster than otherwise.
>>
>> m_file = CreateFileA(
>>                                         filename,
>>                                         GENERIC_READ,
>>                                         0,
>>                                         0,
>>                                         OPEN_EXISTING,
>>                                         FILE_FLAG_SEQUENTIAL_SCAN |
>> FILE_ATTRIBUTE_READONLY | FILE_ATTRIBUTE_TEMPORARY,
>>                                         0);
>>
>> but CreateFileA is failing for us at runtime when compiled on many
>> other systems.
>
> Failing how?  Is there an error code when it fails returned by
> GetLastError?  If so, what is the code?
>
>>   mint17 64 bit:
>> binutils-mingw-w64-i686  2.23.52.20130620-1ubuntu1+3build1
>> g++-mingw-w64-i686   4.8.2-10ubuntu2+12
>> gcc-mingw-w64-base  4.8.2-10ubuntu2+12
>> gcc-mingw-w64-i686   4.8.2-10ubuntu2+12
>> mingw-w64-common     3.1.0-1
>> mingw-w64-i686-dev     3.1.0-1
>>
>>   But it works when compiled on fed14 amd64 (for win32)
>> mingw32-pthreads-2.8.0-10.fc13.noarch
>> mingw32-runtime-3.15.2-5.fc13.noarch
>> mingw32-w32api-3.14-1.fc14.noarch
>> mingetty-1.08-4.fc12.x86_64
>> mingw32-filesystem-64-2.fc14.noarch
>> mingw32-gcc-4.5.0-1.fc14.x86_64
>> mingw32-binutils-2.20.1-2.fc14.x86_64
>> mingw32-cpp-4.5.0-1.fc14.x86_64
>> mingw32-gcc-c++-4.5.0-1.fc14.x86_64
>
> These versions seem to be old, in both cases.  Not sure if that's
> related.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:[hidden email]?subject=unsubscribe

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: CreateFileA issue

Eli Zaretskii
> Date: Sat, 2 Jan 2016 23:18:17 +1000
> From: Steve A <[hidden email]>
>
> If i can figure out how to see GetLastError()
> i will let you know, but stdout is missing of course
> and our custom wish does not have a "console".

Open a file and write the error to it.

> I think i should be able to, but I am more a wish programmer than C.
> (The CreateFileA code in question is contributed.)
> At the moment CreateFileA just returns INVALID_HANDLE_VALUE

Can you show the shortest C program using this call that exhibits the
problem?

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: CreateFileA issue

Steve A
Our problem was the CreateFileA share permissions, which had
previously worked fine as NULL, now need to be "FILE_SHARE_READ |
FILE_SHARE_WRITE". (Using either one of these alone does not work).
thanks again, Steven

On Sun, Jan 3, 2016 at 9:26 AM, Steve A <[hidden email]> wrote:

> Sorry mate - maybe we have opened it already.
> Will check it out and get back to you.
>
>
> On Sun, Jan 3, 2016 at 8:46 AM, Steve A <[hidden email]> wrote:
>> The same error result is given if i replace the
>> FILE_FLAG_SEQUENTIAL_SCAN with FILE_ATTRIBUTE_NORMAL
>>
>> And also if i replace the share flag with FILE_SHARE_READ or
>> FILE_SHARE_WRITE  while using FILE_ATTRIBUTE_NORMAL
>>
>> ... Sorry - it's a bit hard for me to make simple program/case.
>>
>>
>> On Sun, Jan 3, 2016 at 7:47 AM, Steve A <[hidden email]> wrote:
>>> ERROR_SHARING_VIOLATION 32 (0x20)
>>> "The process cannot access the file because it is being used by
>>> another process."
>>>
>>> But i'm doubtful our program has opened it at all at this stage.
>>> Especially since it works fine on Fed14.
>>>
>>> thanks
>>>
>>>
>>>
>>> On Sat, Jan 2, 2016 at 11:28 PM, Eli Zaretskii <[hidden email]> wrote:
>>>>> Date: Sat, 2 Jan 2016 23:18:17 +1000
>>>>> From: Steve A <[hidden email]>
>>>>>
>>>>> If i can figure out how to see GetLastError()
>>>>> i will let you know, but stdout is missing of course
>>>>> and our custom wish does not have a "console".
>>>>
>>>> Open a file and write the error to it.
>>>>
>>>>> I think i should be able to, but I am more a wish programmer than C.
>>>>> (The CreateFileA code in question is contributed.)
>>>>> At the moment CreateFileA just returns INVALID_HANDLE_VALUE
>>>>
>>>> Can you show the shortest C program using this call that exhibits the
>>>> problem?

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: CreateFileA issue

Steve A
Actually, our problem is not resolved.
The above fix works for g++-mingw-w64-i686, but not for our 64 bit system, where calling the CreateFileA API
succeeds, but performance is reduced 10 fold or so over the normal file open and read.  :(

And i see now that there are two separate projects. mingw and ming-w64.

The bug could be solely in ming-w64, as it is not evidient on my Fed144/MinGW system.
 If someone from MinGW-W64 could email me with any ideas, it would be appreciated.
Thanks



On Sun, Jan 3, 2016 at 9:43 PM, Steve A <[hidden email]> wrote:
Our problem was the CreateFileA share permissions, which had
previously worked fine as NULL, now need to be "FILE_SHARE_READ |
FILE_SHARE_WRITE". (Using either one of these alone does not work).
thanks again, Steven

On Sun, Jan 3, 2016 at 9:26 AM, Steve A <[hidden email]> wrote:
> Sorry mate - maybe we have opened it already.
> Will check it out and get back to you.
>
>
> On Sun, Jan 3, 2016 at 8:46 AM, Steve A <[hidden email]> wrote:
>> The same error result is given if i replace the
>> FILE_FLAG_SEQUENTIAL_SCAN with FILE_ATTRIBUTE_NORMAL
>>
>> And also if i replace the share flag with FILE_SHARE_READ or
>> FILE_SHARE_WRITE  while using FILE_ATTRIBUTE_NORMAL
>>
>> ... Sorry - it's a bit hard for me to make simple program/case.
>>
>>
>> On Sun, Jan 3, 2016 at 7:47 AM, Steve A <[hidden email]> wrote:
>>> ERROR_SHARING_VIOLATION 32 (0x20)
>>> "The process cannot access the file because it is being used by
>>> another process."
>>>
>>> But i'm doubtful our program has opened it at all at this stage.
>>> Especially since it works fine on Fed14.
>>>
>>> thanks
>>>
>>>
>>>
>>> On Sat, Jan 2, 2016 at 11:28 PM, Eli Zaretskii <[hidden email]> wrote:
>>>>> Date: Sat, 2 Jan 2016 23:18:17 +1000
>>>>> From: Steve A <[hidden email]>
>>>>>
>>>>> If i can figure out how to see GetLastError()
>>>>> i will let you know, but stdout is missing of course
>>>>> and our custom wish does not have a "console".
>>>>
>>>> Open a file and write the error to it.
>>>>
>>>>> I think i should be able to, but I am more a wish programmer than C.
>>>>> (The CreateFileA code in question is contributed.)
>>>>> At the moment CreateFileA just returns INVALID_HANDLE_VALUE
>>>>
>>>> Can you show the shortest C program using this call that exhibits the
>>>> problem?


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: CreateFileA issue

Eli Zaretskii
> Date: Sat, 9 Jan 2016 09:52:51 +1000
> From: Steve A <[hidden email]>
>
> Actually, our problem is not resolved.
> The above fix works for g++-mingw-w64-i686, but not for our 64 bit system,
> where calling the CreateFileA API
> succeeds, but performance is reduced 10 fold or so over the normal file open
> and read. :(
>
> And i see now that there are two separate projects. mingw and ming-w64.
>
> The bug could be solely in ming-w64, as it is not evidient on my Fed144/MinGW
> system.
> If someone from MinGW-W64 could email me with any ideas, it would be
> appreciated.

If you are running a 32-bit build on a 64-bit Windows OS, the slower
performance is expected, since every system call needs to go through
the WOW64 thunking levels.  10-fold performance hit in such cases is
not unheard of, if the program does little except working with file
I/O.

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: CreateFileA issue

Steve A
It is a MinGW-W64 compiled 64 bit binary (compiled on 32 bit mint15)

The 10 fold performance slowdown is over normal file I/O.
It is actually something like 50 fold slower than the working MinGW and MinGW-W64 32 bit binaries executed on a win64 system.

cheers

DISTRIB_DESCRIPTION="Linux Mint 15 Olivia"
NAME="Ubuntu"
VERSION="13.04, Raring Ringtail"

mingw-w64                  2.0.3-1
mingw-w64-x86-64-dev       2.0.3-1



On Sat, Jan 9, 2016 at 5:02 PM, Eli Zaretskii <[hidden email]> wrote:
> Date: Sat, 9 Jan 2016 09:52:51 +1000
> From: Steve A <[hidden email]>
>
> Actually, our problem is not resolved.
> The above fix works for g++-mingw-w64-i686, but not for our 64 bit system,
> where calling the CreateFileA API
> succeeds, but performance is reduced 10 fold or so over the normal file open
> and read. :(
>
> And i see now that there are two separate projects. mingw and ming-w64.
>
> The bug could be solely in ming-w64, as it is not evidient on my Fed144/MinGW
> system.
> If someone from MinGW-W64 could email me with any ideas, it would be
> appreciated.

If you are running a 32-bit build on a 64-bit Windows OS, the slower
performance is expected, since every system call needs to go through
the WOW64 thunking levels.  10-fold performance hit in such cases is
not unheard of, if the program does little except working with file
I/O.


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: CreateFileA issue

Eli Zaretskii
> Date: Sat, 9 Jan 2016 17:23:36 +1000
> From: Steve A <[hidden email]>
>
> It is a MinGW-W64 compiled 64 bit binary (compiled on 32 bit mint15)

Then you are posting to the wrong mailing list.  This mailing list is
for mingw.org's MinGW project, which doesn't (yet) support 64-bit
builds.

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe