Re: looking for work-around: _d_assocarrayliteralTX segfault assigning a shared associative array an AA literal
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
Re: looking for work-around: _d_assocarrayliteralTX segfault assigning a shared associative array an AA literal
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
Re: looking for work-around: _d_assocarrayliteralTX segfault assigning a shared associative array an AA literal
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
Re: looking for work-around: _d_assocarrayliteralTX segfault assigning a shared associative array an AA literal
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
Union with bits ?
I would like to have labeled bits in a union with a ubyte.
Something like this:
```d
struct MyStruct {
union {
ubyte status;
bit A, B, C…etc
}
}
```
Is something like this possible?
Thanks
Re: looking for hint to debug a strange multi-thread bug (grpc-d-core)
UPDATE: life is too short to debug dlang built-in AA to right, let's just use HashMap from emsi_containers https://github.com/mw66/grpc-d/blob/master/source/grpc/server/package.d#L25 ``` HashMap!(string, ServiceHandlerInterface) services; ``` After this change, the problem goes away. I think there are some bugs in the builtin AA implementation, as demo-ed in this multi-threaded program (maybe also related to GC?).
Re: looking for work-around: _d_assocarrayliteralTX segfault assigning a shared associative array an AA literal
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.
looking for hint to debug a strange multi-thread bug (grpc-d-core)
Hi,
I recently found and started playing with the grpc-d-core[1]
package, and my program structure looks like this:
https://github.com/mw66/grpc-demo/blob/master/source/main.d
If I run L64 alone (without L66 ~ 79 grpc-d part):
```
64: auto t = new Thread({fun();}).start();
```
it works fine.
If I run L66 ~ 79 grpc-d part alone (without L64), it also works
fine.
But if I run both, the program received signal SIGSEGV,
Segmentation fault at here:
https://github.com/mw66/grpc-d/blob/master/source/grpc/server/package.d#L94
with LDC, the print out of `services.keys` shows its corrupted
with some strange values.
under DMD, it fails at:
https://github.com/mw66/grpc-d/blob/master/source/grpc/server/package.d#L99
while the `services.keys` seems fine.
What puzzles me is that: these two parts of the code are actually
independent, does not know each other at all (as I just started
to add the grpc-d skeleton code with dummy returns, and no client
connected or made any rpc calls).
And the `services` defined here is a private class field:
https://github.com/mw66/grpc-d/blob/master/source/grpc/server/package.d#L21
So how can it be corrupted by `fun()`?
Any suggestions where should I look into?
Thanks.
[1] https://code.dlang.org/packages/grpc-d-core
Re: compile-time detection of all pointer types in one test
On Sunday, 11 June 2023 at 21:32:11 UTC, Andy wrote:
[...]
void main() {
import std.stdio;
struct foo {}
foo* fooptr;
static if (is(typeof(fooptr) == T*, T))
writeln("fooptr is a pointer to a ", T.stringof);
else
writeln("fooptr is not a pointer");
}
Unfortunately, testing more than one variable:
```
void main() {
import std.stdio;
struct foo1 {int foo1int; char foo1char;}
foo1* foo1ptr;
struct foo2 {int foo2int; char foo2char;}
foo2* foo2ptr;
static if (is(typeof(foo1ptr) == T*, T))
writeln("foo1ptr is a pointer to a ", T.stringof);
else
writeln("foo1ptr is not a pointer");
static if (is(typeof(foo2ptr) == T*, T))
writeln("foo2ptr is a pointer to a ", T.stringof);
else
writeln("foo2ptr is not a pointer");
}
```
produced
```
static_if_ex05.d(16): Error: declaration `T` is already defined
static_if_ex05.d(11):`alias` `T` is defined here
```
Re: looking for work-around: _d_assocarrayliteralTX segfault assigning a shared associative array an AA literal
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.
0x77de2239 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.
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
Re: looking for work-around: _d_assocarrayliteralTX segfault assigning a shared associative array an AA literal
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.
Re: looking for work-around: _d_assocarrayliteralTX segfault assigning a shared associative array an AA literal
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;
}
```
Re: assert/static assert message format difference
On Tuesday, 13 June 2023 at 16:46:26 UTC, DLearner wrote:
Only a small thing, but is it intended that:
```
void main() {
// static assert (false, "Static Assert triggered");
assert(false, "Assert triggered");
}
```
produces
```
core.exception.AssertError@staticassertex01.d(4): Assert
triggered
```
but removing the // produces
```
staticassertex01.d(3): Error: static assert: "Static Assert
triggered"
```
ie message surrounded by double-quotes?
internal detail.
Static assert will render the message by formatting an AST node,
i.e the StringExp (as the string has to be statically evaluable),
using a compiler module called the hdrgen, leading to have the
double quotes included, because the hdrgen is supposed to give
back the source code for a particulat node.
Runtime assert only know the string ptr and len, which are
runtime values. So... in that case it's more like a format %s,
that takes another path.
assert/static assert message format difference
Only a small thing, but is it intended that:
```
void main() {
// static assert (false, "Static Assert triggered");
assert(false, "Assert triggered");
}
```
produces
```
core.exception.AssertError@staticassertex01.d(4): Assert triggered
```
but removing the // produces
```
staticassertex01.d(3): Error: static assert: "Static Assert
triggered"
```
ie message surrounded by double-quotes?
