Unclear segmentation fault error caused by differing schedule read/writes

[SamuelCupp]

I have a function scheduled in two different bins. I had accidentally left off one group in the WRITE declarations for the second scheduling. The macro properly gave declared variables (macro is a union of all READ/WRITE declarations), so there was no compile-time error. However, at runtime a segmentation fault occurred because the second scheduling didn't declare that it would use that variable.

This is with "presync-only", if that matters.

The behavior of not allowing memory access is reasonable, but it was not obvious at all that the issue was with the scheduling. Should there be some sort of warning if a function has different read/writes that might trigger such an error? This could be a difficult error to track down for someone less familiar with PreSync and CarpetX.

[eschnett]

I wonder why this led to a segfault. I would have expected an "undefined variable" or "writing to a const variable" compile-time error instead. Which macros are you using to declare the grid functions?

It is likely that this is handled by the flesh, in which case @stevenrbrandt will know more about this.

[stevenrbrandt]

This is by design. In presync-only, if you try to access a variable you have not declared access to, and you circumvent the compile time checks of the macro, you get a nullptr.

[SamuelCupp]

The reason it leads to a segfault is because the macros (I'm assuming the X variant inherited the same behavior as my implementation) takes a union of all read/writes and declares those variables. However, as Steve said this is distinct from the actual read/writes of an individual scheduled function. Thus, if I have

`schedule f in A

reads v1, v2

writes v3, v4
`

and later have

`schedule f in B

reads v1, v2

writes v3
`

Then the macro will declare v1, v2, v3, and v4. However, if the function f scheduled in B actually tries to access v4 there will be a segfault. Both of these things are correct behavior. The macro must be a union of all declarations for the code to compile. And if a function actually changes its access based on some runtime parameters or other scheduling, it shouldn't have access to the variables that it doesn't declare.

The only thing that I believe would be helpful is a warning that a given function has different declarations. If we really wanted, we could add the ability to turn off the warning by saying somewhere in the ccl "yes, this function should have different access depending on where it is scheduled".

[stevenrbrandt]

Yes, you have described things correctly. We could add a warning if there are multiple declarations.