June 13, 2023

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

June 14, 2023

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?).