www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - BetterC and Windows API calls

reply pineapple <meapineapple gmail.com> writes:
I've been experimenting a bit with betterC recently, and I've 
found that a trivial use of `QueryPerformanceFrequency` (the 
extern declaration imported from `core.sys.windows.winbase`) 
immediately crashes my program with status code 3221225477.

https://github.com/pineapplemachine/scamp.d/blob/master/src/scamp/time/monotonic.d#L76

What's going on here? The same code works as expected, without 
crashing, if I compile without -betterC.

Before this, I found that trying to use the 
`core.sys.windows.winbase` module's convenience overrides that 
accept a long pointer instead of a LARGE_INTEGER struct pointer 
would result in a linker error when compiling with -betterC.

Is there something I need to be doing differently to make Windows 
API calls, or is this a bug with betterC?
Jun 02 2023
next sibling parent bauss <jacobbauss gmail.com> writes:
On Friday, 2 June 2023 at 19:19:57 UTC, pineapple wrote:

 I've been experimenting a bit with betterC recently, and I've 
 found that a trivial use of `QueryPerformanceFrequency` (the 
 extern declaration imported from `core.sys.windows.winbase`) 
 immediately crashes my program with status code 3221225477.

 https://github.com/pineapplemachine/scamp.d/blob/master/src/scamp/time/monotonic.d#L76

 What's going on here? The same code works as expected, without 
 crashing, if I compile without -betterC.

 Before this, I found that trying to use the 
 `core.sys.windows.winbase` module's convenience overrides that 
 accept a long pointer instead of a LARGE_INTEGER struct pointer 
 would result in a linker error when compiling with -betterC.

 Is there something I need to be doing differently to make 
 Windows API calls, or is this a bug with betterC?


If it works without -betterC and crashes when toggled on, then 
I'm going to assume it's either a bug or memory was corrupted 
before said call to QueryPerformanceFrequency.

Try to isolate the call and see if it crashes with nothing else.
Jun 02 2023
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/2/23 3:19 PM, pineapple wrote:

 I've been experimenting a bit with betterC recently, and I've found that 
 a trivial use of `QueryPerformanceFrequency` (the extern declaration 
 imported from `core.sys.windows.winbase`) immediately crashes my program 
 with status code 3221225477.
 
 https://github.com/pineapplemachine/scamp.d/blob/master/src/scamp/time/monotonic.d#L76
 
 What's going on here? The same code works as expected, without crashing, 
 if I compile without -betterC.
 
 Before this, I found that trying to use the `core.sys.windows.winbase` 
 module's convenience overrides that accept a long pointer instead of a 
 LARGE_INTEGER struct pointer would result in a linker error when 
 compiling with -betterC.
 
 Is there something I need to be doing differently to make Windows API 
 calls, or is this a bug with betterC?


That error code is 0xC0000005, which is an access violation (segfault). 
Basically, a memory read/write error.

Using static in D means TLS. I'm not sure what the rules are for TLS and 
betterC, but perhaps it's not properly set up?

Maybe try __gshared instead of static? Not sure.

-Steve
Jun 02 2023
parent reply pineapple <meapineapple gmail.com> writes:
On Friday, 2 June 2023 at 21:23:46 UTC, Steven Schveighoffer 
wrote:

 That error code is 0xC0000005, which is an access violation 
 (segfault). Basically, a memory read/write error.

 Using static in D means TLS. I'm not sure what the rules are 
 for TLS and betterC, but perhaps it's not properly set up?

 Maybe try __gshared instead of static? Not sure.

 -Steve


Ahh, I had not even got around to considering that accessing the 
`static` declaration could be the problem. That seems like a bug?

Anyway, declaring it as either `static shared` or `static 
__gshared` fixes the crash - thanks for pointing me to that!
Jun 03 2023
parent reply Dave P. <dave287091 gmail.com> writes:
On Saturday, 3 June 2023 at 08:13:30 UTC, pineapple wrote:

 On Friday, 2 June 2023 at 21:23:46 UTC, Steven Schveighoffer 
 wrote:

 That error code is 0xC0000005, which is an access violation 
 (segfault). Basically, a memory read/write error.

 Using static in D means TLS. I'm not sure what the rules are 
 for TLS and betterC, but perhaps it's not properly set up?

 Maybe try __gshared instead of static? Not sure.

 -Steve


 Ahh, I had not even got around to considering that accessing 
 the `static` declaration could be the problem. That seems like 
 a bug?

 Anyway, declaring it as either `static shared` or `static 
 __gshared` fixes the crash - thanks for pointing me to that!


Still file an issue though, TLS should either work or fail to 
compile, not crash at runtime.
Jun 03 2023
next sibling parent IGotD- <nise nise.com> writes:
On Saturday, 3 June 2023 at 16:39:54 UTC, Dave P. wrote:

 Still file an issue though, TLS should either work or fail to 
 compile, not crash at runtime.


No, it should still be possible to compile TLS into the binary 
because someone might have done a bespoke TLS implementation. We 
cannot block that possibility.
Jun 03 2023
prev sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 04/06/2023 4:39 AM, Dave P. wrote:

 Still file an issue though, TLS should either work or fail to compile, 
 not crash at runtime.


Its a known issue, ryuuckk has ran into it.

It might be fixed as of 2.104, nobody has checked I think.

https://issues.dlang.org/show_bug.cgi?id=20737
Jun 03 2023
parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Saturday, 3 June 2023 at 17:27:48 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 On 04/06/2023 4:39 AM, Dave P. wrote:

 Still file an issue though, TLS should either work or fail to 
 compile, not crash at runtime.


 Its a known issue, ryuuckk has ran into it.

 It might be fixed as of 2.104, nobody has checked I think.

 https://issues.dlang.org/show_bug.cgi?id=20737


Yes it is fixed with 2.104 
https://dlang.org/changelog/2.104.0.html
Jun 04 2023