https://issues.dlang.org/show_bug.cgi?id=20812

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" ];
}

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.

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 above, 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.

On Tuesday, 13 June 2023 at 17:06:55 UTC, mw wrote:

I don't know if it's correct or not, but I think I did this at the time to work around it.

shared string[string] aa;

void main()
{
    auto aaTemp = [ "abc" : "123" ];
    aa = cast(shared)aaTemp;
}

On Tuesday, 13 June 2023 at 17:12:41 UTC, Anonymouse wrote:

shared string[string] aa;

void main()
{
    auto aaTemp = [ "abc" : "123" ];
    aa = cast(shared)aaTemp;
}

Thanks, I just did a simple test:

https://gist.github.com/run-dlang/88cefdde8bb7f61f173ad11b2a03d5ee

(BTW, https://run.dlang.org/ is not stable these few days).

import core.thread;
import std;
import std.parallelism;

shared string[string] aa;

void fun() {
  foreach (i; 0 .. 5) {
    writeln("fun", i, aa);
    foreach (num; parallel(iota(5))) {
        // writeln(num);
    }
    Thread.sleep(5.seconds);
  }
}


void main() {
    writeln("start", aa);
    auto aaTemp = [ "abc" : "123" ];
    aa = cast(shared)aaTemp;
    writeln(aa);
    foreach (num; parallel(iota(5))) {
      auto t = new Thread({fun();}).start();
    }
}

run result:

start[]
["abc":"123"]
fun0["abc":"123"]
fun0["abc":"123"]
fun0["abc":"123"]
fun0["abc":"123"]
fun0["abc":"123"]
fun1["abc":"123"]
fun1["abc":"123"]
fun1["abc":"123"]
fun1["abc":"123"]
fun1["abc":"123"]
fun2["abc":"123"]
fun2["abc":"123"]
fun2["abc":"123"]
fun2["abc":"123"]
fun2["abc":"123"]
fun3["abc":"123"]
fun3["abc":"123"]
fun3["abc":"123"]
fun3["abc":"123"]
fun3["abc":"123"]
fun4["abc":"123"]
fun4["abc":"123"]
fun4["abc":"123"]
fun4["abc":"123"]
fun4["abc":"123"]

looks like different threads can read the same aa contents. So at least it's working.

On 6/13/23 1:06 PM, mw wrote:

GDC also fails.

shared string[string] aa;

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

I tried the memoryerror registration, but that doesn't give any more information.

It's unfortunate that LDC works, as that comes with a debug-built druntime/phobos you can use.

As far as I can tell, this problem has been occurring for a long time.

BTW, you don't need to define it in global space, just:

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

-Steve

On Tuesday, 13 June 2023 at 22:21:10 UTC, Steven Schveighoffer wrote:

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

I have to ask the old-timers on this forums: looks like the dlang built-in AA has caused us too many problems, I'm just wondering which (dict / map) library on https://code.dlang.org/ provides the best (reliable and convenient) drop-in replacement of the built-in AA?

Thanks.

On 6/13/23 8:02 PM, mw wrote:

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

I started one, but haven't fleshed out all the pieces:

https://code.dlang.org/packages/newaa

This is literally a drop-in replacement for an AA as it uses exactly the same algorithms and layout. In fact, you can cast it to an equivalent aa and it works.

I would accept PRs and issues if you want to use it. The hard parts are done, it just needs API.

-Steve

On 6/13/23 1:06 PM, mw wrote:

Built a debug version of dmd/druntime, the failure is here:

https://github.com/dlang/dmd/blob/342a226833a0e9c7a90bbb64ae8dc35aa6d6bfdc/druntime/src/rt/aaA.d#L766

The line is:

immutable keysz = ti.key.tsize;

From the debugger, I can tell that ti.key is null. So that is the segfault.

I need to diagnose further, but most likely the problem is that the typeinfo being passed is incorrect (I believe it's a TypeInfo_Shared, but the function is expecting a TypeInfo_AssociativeArray)

-Steve

On 6/13/23 10:02 PM, Steven Schveighoffer wrote:

Further diagnosis is that the TypeInfo being passed in is still wrapped in a TypeInfo_Shared.

If you do const aa = ["abc": "123"] or immutable aa = ["abc": "123"] then the typeinfo is not wrapped in TypeInfo_Const or TypeInfo_Shared

This explains exactly why there is a bug.

I put the following line at the top of that function, and it fails in the shared case:

assert(typeid(ti) == typeid(TypeInfo_AssociativeArray));

If there isn't a bug I'll file one.

-Steve

On 6/13/23 10:14 PM, Steven Schveighoffer wrote:

OMG I didn't even see that the first line of your post is the bug report!

I added to it.

-Steve