www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - looking for work-around: _d_assocarrayliteralTX segfault assigning a

reply mw <mingwu gmail.com> writes:
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" ];
}
```

 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 



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.
Jun 13 2023
next sibling parent reply Anonymouse <zorael gmail.com> writes:
On Tuesday, 13 June 2023 at 17:06:55 UTC, mw wrote:

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


 Thanks.


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;
}
```
Jun 13 2023
parent mw <mingwu gmail.com> writes:
On Tuesday, 13 June 2023 at 17:12:41 UTC, Anonymouse wrote:

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

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


 Thanks.


 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;
 }
 ```


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.
Jun 13 2023
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/13/23 1:06 PM, mw wrote:

 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.


GDC also fails.


 ```
 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 



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:

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

-Steve
Jun 13 2023
parent reply mw <mingwu gmail.com> writes:
On Tuesday, 13 June 2023 at 22:21:10 UTC, Steven Schveighoffer 
wrote:

 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:

 ```d
 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.
Jun 13 2023
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/13/23 8:02 PM, mw wrote:

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

 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:

 ```d
 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?


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
Jun 13 2023
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/13/23 1:06 PM, mw wrote:

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


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:

```d
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
Jun 13 2023
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/13/23 10:02 PM, Steven Schveighoffer wrote:


 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)
 


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:

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

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

-Steve
Jun 13 2023
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/13/23 10:14 PM, Steven Schveighoffer wrote:

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


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

I added to it.

-Steve
Jun 13 2023