What bug through yonder weirdness my build breaks?
We have a lot of tests for RavenDB, and we are running them on plenty of environments. We semi frequently get a build failure when running on the “macOS latest” runner on GitHub.
The problem is that the information that I have is self-contradicting. Here is the most relevant piece:
Here you can see the failure itself and what is causing it.
Note that the debug message is showing that all three variables here have the same numeric value. The address and the current variables are also held on the stack, so there is no option for race conditions, or something like that.
I can’t figure out any reason why this would be triggered, in this case. About the only thing that pops to mind is whether there is some weirdness going on with pointer comparisons on MacOS, but I don’t have a lead to follow.
We haven’t investigated it properly yet, I thought to throw this to the blog and see if you have any idea what may be going on here.
Comments
Perhaps I've missed something, but isn't that assert expected in this case? Those two values are equal, thus the invariant is false, thus
Debug.Assert
should raise the assertion.Christopher is correct. The Assert message should be reporting the OPPOSITE of the failed assertion. In other words, the problem is that occasionally both address and current point to the same memory location, while the Assert is stating that they should never be the same.
Could it be that the compiler does not create a stack local variable for address and or current and then you are seeing the weak ARM Memory model which has much more race conditions than on x86 CPUs? Otherwise the results are indeed impossible.
allocation for zero bytes?
Christopher, EvilKiru,
You didn't miss anything, my eyes did :-)
Alois,
The .NET memory model means that it cannot do so, I think.
Rafal
No, there should always be a size here.
Comment preview