digitalmars.D.learn - std.format doesn't want to work
- solidstate1991 (7/7) Oct 16 2021 When I make this call
- frame (5/12) Oct 16 2021 I think it would be helpful to know what type avgFPS is and what
- russhy (3/10) Oct 16 2021 what is the type of avgFPS?
- solidstate1991 (3/14) Oct 17 2021 I's a double, but I've tried to pass it as real and float too,
- jfondren (6/21) Oct 17 2021 then it's likely that some memory corruption prior to format()
- solidstate1991 (4/10) Oct 17 2021 I ran Valgrind, and I've noticed some possible leakage in a
- Steven Schveighoffer (10/18) Oct 17 2021 FYI, solidstate figured this out. It was because of an out-of-bounds
- user1234 (7/27) Oct 18 2021 contracts ?
- Steven Schveighoffer (4/36) Oct 18 2021 Even a template may not help, if the compiler decides it's already been
When I make this call
```
format(" %3.3f"w, avgFPS);
```
my program immediately crashes with an access violation error.
The debugger out is different between x86 and x86-64.
I've made all sanity checks, so I need some other suggestions.
Oct 16 2021
frame <frame86 live.com>
On Saturday, 16 October 2021 at 22:47:09 UTC, solidstate1991
wrote:
When I make this call
```
format(" %3.3f"w, avgFPS);
```
my program immediately crashes with an access violation error.
The debugger out is different between x86 and x86-64.
I've made all sanity checks, so I need some other suggestions.
I think it would be helpful to know what type avgFPS is and what
you do with the output of format(). Access violation is mostly an
access to a null pointer.
Oct 16 2021
On Saturday, 16 October 2021 at 22:47:09 UTC, solidstate1991
wrote:
When I make this call
```
format(" %3.3f"w, avgFPS);
```
my program immediately crashes with an access violation error.
The debugger out is different between x86 and x86-64.
I've made all sanity checks, so I need some other suggestions.
what is the type of avgFPS?
Oct 16 2021
On Sunday, 17 October 2021 at 05:22:17 UTC, russhy wrote:On Saturday, 16 October 2021 at 22:47:09 UTC, solidstate1991 wrote:I's a double, but I've tried to pass it as real and float too, with the same exact error being generated.When I make this call ``` format(" %3.3f"w, avgFPS); ``` my program immediately crashes with an access violation error. The debugger out is different between x86 and x86-64. I've made all sanity checks, so I need some other suggestions.what is the type of avgFPS?
Oct 17 2021
On Sunday, 17 October 2021 at 12:53:07 UTC, solidstate1991 wrote:On Sunday, 17 October 2021 at 05:22:17 UTC, russhy wrote:then it's likely that some memory corruption prior to format() has broken the GC, and format's allocation of a string is what's failing. Try sprinkling ` safe` and and see what it complains about; try valgrind; try reducing your problem. I don't think we can help you more without a way to replicate the fault.On Saturday, 16 October 2021 at 22:47:09 UTC, solidstate1991 wrote:I's a double, but I've tried to pass it as real and float too, with the same exact error being generated.When I make this call ``` format(" %3.3f"w, avgFPS); ``` my program immediately crashes with an access violation error. The debugger out is different between x86 and x86-64. I've made all sanity checks, so I need some other suggestions.what is the type of avgFPS?
Oct 17 2021
On Sunday, 17 October 2021 at 13:03:46 UTC, jfondren wrote:then it's likely that some memory corruption prior to format() has broken the GC, and format's allocation of a string is what's failing. Try sprinkling ` safe` and and see what it complains about; try valgrind; try reducing your problem. I don't think we can help you more without a way to replicate the fault.I ran Valgrind, and I've noticed some possible leakage in a library I've written, but I'll check for it further once I'll have a bit more time.
Oct 17 2021
On 10/16/21 6:47 PM, solidstate1991 wrote:
When I make this call
```
format(" %3.3f"w, avgFPS);
```
my program immediately crashes with an access violation error. The
debugger out is different between x86 and x86-64.
I've made all sanity checks, so I need some other suggestions.
FYI, solidstate figured this out. It was because of an out-of-bounds
index on `BitArray`.
But that irks me. Why wouldn't `BitArray` do a bounds check? And then I
remembered -- Phobos is built in release mode even when your app is not.
I literally *cannot* request from the compiler that `BitArray` enforce
its contracts without rebuilding the library completely. I never want to
build code that doesn't have bounds checks.
How can we fix this?
-Steve
Oct 17 2021
On Sunday, 17 October 2021 at 21:00:19 UTC, Steven Schveighoffer wrote:On 10/16/21 6:47 PM, solidstate1991 wrote:contracts ? bound checks should be in the body and conditionally compiled with `version(D_NoBoundsChecks){} else {}` then same problem because it's not a function template I guess. someone should make it a function template then.When I make this call ``` format(" %3.3f"w, avgFPS); ``` my program immediately crashes with an access violation error. The debugger out is different between x86 and x86-64. I've made all sanity checks, so I need some other suggestions.FYI, solidstate figured this out. It was because of an out-of-bounds index on `BitArray`. But that irks me. Why wouldn't `BitArray` do a bounds check? And then I remembered -- Phobos is built in release mode even when your app is not. I literally *cannot* request from the compiler that `BitArray` enforce its contracts without rebuilding the library completely. I never want to build code that doesn't have bounds checks. How can we fix this? -Steve
Oct 18 2021
On 10/18/21 8:35 AM, user1234 wrote:On Sunday, 17 October 2021 at 21:00:19 UTC, Steven Schveighoffer wrote:Even a template may not help, if the compiler decides it's already been instantiated. -SteveOn 10/16/21 6:47 PM, solidstate1991 wrote:contracts ? bound checks should be in the body and conditionally compiled with `version(D_NoBoundsChecks){} else {}` then same problem because it's not a function template I guess. someone should make it a function template then.When I make this call ``` format(" %3.3f"w, avgFPS); ``` my program immediately crashes with an access violation error. The debugger out is different between x86 and x86-64. I've made all sanity checks, so I need some other suggestions.FYI, solidstate figured this out. It was because of an out-of-bounds index on `BitArray`. But that irks me. Why wouldn't `BitArray` do a bounds check? And then I remembered -- Phobos is built in release mode even when your app is not. I literally *cannot* request from the compiler that `BitArray` enforce its contracts without rebuilding the library completely. I never want to build code that doesn't have bounds checks. How can we fix this?
Oct 18 2021