Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions .cargo/config
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@
[target.x86_64-pc-windows-msvc]
rustflags = ["-C", "link-arg=/STACK:8388608"]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what to do about this either, it's required in a project that uses swiftnav-rs and here as well, apparently this is by design for how rust links with native libraries:

https://doc.rust-lang.org/beta/unstable-book/language-features/link-args.html

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is is something in our code that requires the 8 MB stack size specifically?

Copy link
Contributor Author

@silverjam silverjam Jan 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice to understand this change more, but during compilation things will crash with a thread 'main' has overflowed its stack error otherwise-- I think 4MiB worked, 8MiB was a "just in case" value.

LSN on windows uses the stack by default for allocation-- but this is a runtime thing-- I don't think it would causes issues until something was actually invoked. Nevertheless I tried to enable heap allocation with some compiler flags and it didn't seem to affect this issue.

This made me think it might be a huge table somewhere that gets initialize as part of setting up globals, like the geoid grid... I tried disabling the compilation of the geoid grid but that didn't help.

Didn't try anything else past this though.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're probably right. I'm cool if this is a workaround, maybe we can investigate it later.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, this is definitely a workaround for now, at some point we can (hopefully) revisit and see if we can track down what's requiring such a large stack

3 changes: 2 additions & 1 deletion src/ephemeris.rs
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,8 @@ type Result<T> = std::result::Result<T, InvalidEphemeris>;

/// Various statuses that an ephemeris can be in
#[derive(Copy, Clone, Debug)]
#[repr(u32)]
#[cfg_attr(windows, repr(i32))]
#[cfg_attr(not(windows), repr(u32))]
Comment on lines +39 to +40
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should instead switch to repr(C)? Based on this in the reference: https://doc.rust-lang.org/reference/type-layout.html#reprc-field-less-enums

It sounds like we should maybe abandon this approach in the long term since it risks invoking UB and isn't scalable to particularly weird target/compiler configs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using repr(C) fails with the same issue unfortunately

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunate. Oh well

pub enum Status {
Null = c_bindings::ephemeris_status_t_EPH_NULL,
Invalid = c_bindings::ephemeris_status_t_EPH_INVALID,
Expand Down