Program crash: GC destroys an object unexpectedly

eugene dee0xeed at gmail.com
Sun Sep 19 09:26:14 UTC 2021


On Saturday, 18 September 2021 at 09:54:05 UTC, jfondren wrote:
> On Saturday, 18 September 2021 at 09:39:24 UTC, eugene wrote:
>> The definition of this struct was taken from
>> /usr/include/dmd/druntime/import/core/sys/linux/epoll.d
> ...
>> If the reason for crash was in EpollEvent alignment,
>> programs would segfaults always very soon after start,
>> just right after the very first return from epoll_wait().
>
> The struct's fine as far as libc and the kernel are concerned. 
> epoll_wait is not even using those 64 bits or interpreting them 
> as containing any kind of data, it's just moving them around 
> for the caller to use. It's also not a hardware error to 
> interpret those bits where they are as a pointer.

Exactly.

> They are however not 64-bit aligned so D's GC is collecting 
> objects that only they point to.

Ok...

1) There are 303 event sources in echo-server,
200 in RX machines (100 Ios and 100 Timers),
100 Ios in TX machines and finally 3 in
Listener (one Io and two signals, **sg0 and sg1**)

All of these 303 references in EpollEvent struct are 'misaligned'
in this sense, but **non of corresponding objects are collected**.

2) There are 22 event sources in echo-client,
20 in RX machines (10 Ios and 10 Timers),
10 Ios in TX machines and finally 2 in Stopper machines
(**sg0 and sg1**, for handling SIGINT and SIGTERM),
but **only the two last are collected**, all other are not -
here is the problem.




More information about the Digitalmars-d-learn mailing list