Issue 20812 - _d_assocarrayliteralTX segfault assigning a shared associative array an AA literal
Summary: _d_assocarrayliteralTX segfault assigning a shared associative array an AA li...
Status: NEW
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: x86_64 Linux
: P1 blocker
Assignee: No Owner
URL:
Keywords: safe, wrong-code
Depends on:
Blocks:
 
Reported: 2020-05-08 19:17 UTC by JR
Modified: 2023-06-14 06:23 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description JR 2020-05-08 19:17:02 UTC
Manjaro/Arch x86_64, dmd 2.091.1. ldc does not seem to be affected.

shared string[string] aa;

void main()
{
    aa = [ "abc" : "123" ];
}

> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff7de2239 in _d_assocarrayliteralTX () from /usr/lib/libphobos2.so.0.91

https://run.dlang.io/is/D7AhPD

Could not get a real backtrace into phobos as dmd built with digger crashes when compiling due to issue #18026.
Comment 1 mw 2023-06-13 17:00:00 UTC
Encountered this bug again today with DMD64 D Compiler v2.104.0


You can also try on the run.dlang.org link, the bug still there.


Sigh, we have so many such basic bugs for more than 3 years now, with no fix.


Does anyone know how to fix it? or any work-around?


Thanks.
Comment 2 mail 2023-06-13 21:37:00 UTC
I investigate this bug and the problem is that ti.key (field of TypeInfo_AssociativeArray) is null.

The sigsegv obviously occurs at this line https://github.com/dlang/dmd/blob/342a226833a0e9c7a90bbb64ae8dc35aa6d6bfdc/druntime/src/rt/aaA.d#L766

I'm trying to figure out what the reason for this would be and how to fix it.
Comment 3 Steven Schveighoffer 2023-06-14 02:32:16 UTC
I further diagnosed this. You don't need to declare the shared aa separately, this will do:

```d
void main() { shared aa = ["abc": "123"]; }
```

If you declare `aa` as const instead, the `ti` parameter passed to `_d_assocarrayliteralTX` is a legit `TypeInfo_AssociativeArray`. However, when you use shared, the `ti` parameter is pointing to the wrapping `TypeInfo_Shared`. 

Note that this is a *reinterpret cast*, not a dynamic cast, and so it really thinks it's pointing at a `TypeInfo_AssociativeArray`. Therefore the `key` field doesn't actually exists, and is garbage.

I'm not sure on LDC if this is a similar problem but it's possible since it's reading invalid memory it happens to work? I tend to think not.

I ran on run.dlang.io for all compilers, and all segfault. So this has been happening for a while.

const, immutable, and inout all do not have this problem, only shared.

I also confirmed this is a problem on gdc.