Please run the program with RUST_BACKTRACE=1 you can set this env by export RUST_BACKTRACE=1

It doesn't seem like ArrayFire error, if a GPU runs out of memory, the crate will panic with an error out of memory.

Which OS are you running on ? what is your GPU ?

Dim4 stores u64 values that represent of the length of given dimension(axis). ArrayFire can store array shapes up to 4 dimensions, hence the Dim4. You have to consider the size of array [M N O P] you are creating on the GPU and how much memory your GPU has. Dim4 members being u64, doesn't translate to being capable of having huge array's like [u64_MAX, u64_MAX, 1, 1] - your GPU memory will decide if you can create such Array on GPU.

I never worked with the backtrace, how do I use it correctly on Windows ?
(I used set RUST_BACKTRACE=1 in cmd but it seems like the output does not change)

I'm using Windows 10 64bit with a GeForce GTX 1060 6GB (6144MB).

Ok, I understand that even though the function can take u64 everything is limited by my GPU.
But one million doubles should be 8MB which is way below what it should be capable.

I never worked with the backtrace, how do I use it correctly on Windows ?
(I used set RUST_BACKTRACE=1 in cmd but it seems like the output does not change)

I'm using Windows 10 64bit with a GeForce GTX 1060 6GB (6144MB).

Ok, I understand that even though the function can take u64 everything is limited by my GPU.
But one million doubles should be 8MB which is way below what it should be capable.

True, but it is very unlikely that causes a stack overflow error. I have tried the same snippet on GTX 1060 3GB card and it works fine.

Did you try just the following and check if it works.

fn main() {
 set_device(0);
 info();
 let values: [f64; 1_000_000] = [3.5; 1_000_000];
}

I am not sure if set does the trick environment variables in windows command prompt. I know how to set them in powershell. $Env:RUST_BACKTRACE=1 and you can check if it is set by doing echo $env:RUST_BACKTRACE

Regrading the Powershell:
I did also try it your way but it also doesn't produce a backtrace.

Regarding the overflow:
It seems like you are right and the problem isn't from the Arrayfire or GPU side.
I thought I tested it, but it turns out even

fn main() {
 let values: [f64; 1_000_000] = [3.5; 1_000_000];
}

produces the error. So it seems like the problem originates from rust itself.

On a sidenote:

Rust only stackoverflows in the non-release compiled version, but with Arrayfire it overflows in both cases

It is most likely to do with something like this rust-lang/rust-clippy#4520 but I am not 100% certain - this is something that came up with quick googling. I doubt it can be related to ArrayFire crate if it is failing even in one configuration without ArrayFire Code.

Having said that, I have tried your code on rust play ground seems to work fine for me there as well.
Here is the perma link
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=ff4d73801f87aa4d7951d6f0e80ce683

What is the rust version you are using ?

I figured out what it is:

It is expected that optimizations can affect stack usage. We don't generally give guarantees about this. In particular, Windows' default stack size is only 1 MB, which you are easily exceeding by allocating 1_000_000 doubles.

rust-lang/rust#72922

So sadly the windows stack size does not allow me to allocate more on the GPU. Except passing a Vec might be a solution.

I figured out what it is:

It is expected that optimizations can affect stack usage. We don't generally give guarantees about this. In particular, Windows' default stack size is only 1 MB, which you are easily exceeding by allocating 1_000_000 doubles.

rust-lang/rust#72922

So sadly the windows stack size does not allow me to allocate more on the GPU. Except passing a Vec might be a solution.

That doesn't sound right, do you mean it doesn't allow you to allocate more on the host RAM ? GPU doesn't have any such limitations and rust doesn't control that.

Well, I would assume it doesn't allow me to allocate more on the part of the RAM that is managed by the stack. But I probably can do more on the heap which would help if I could assign a Vector into Array::new.

Array::new takes a slice into a vector. so it should work fine.

Perfect, thanks for all the help 👍