On 7/28/23 4:39 AM, IchorDev wrote:
Issue is, this code I posted actually runs just fine, unlike the real code.
My actual code does this HIGHLY SUSPICIOUS thing when printing their
length each time before using them:
```
766
766
765
766
767
768
768
768
768
768
768
768
768
768
768
768
768
768
768
128000
Error Program exited with code -11
(backtrace:)
#0 0x0000555555670c46 in rt.aaA.Impl.findSlotLookup(ulong, scope
const(void*), scope const(TypeInfo)) inout ()
#1 0x0000555555661592 in _aaInX ()
```
My suspicion would be a race condition in your real code, and no race
condition in this toy code. Second suspicion would be memory corruption
(possibly caused by a race condition).
Therefore I must logically conclude that DRuntime's AAs are cursed!
Unless this is a well-known issue or something...
AAs have worked forever. I've never had problems with them. Not saying
there's not a bug here, maybe there is. But I would be surprised.
Thinking back, I've actually had them cause segfaults in non-threaded
code, maybe `__gshared` was never the cause at all.
All `__gshared` does is give you storage that is accessible from all
threads, but is not typed as `shared`. It doesn't change how the data is
used.
-Steve
