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