[Bug d/101692] Program crushes at unpredictable moment of time

2021-07-31 Thread zed at lab127 dot karelia.ru via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101692

--- Comment #5 from Eugene Zhiganov  ---

Eventually I used following workaround:

RxSm[] rxMachines;
auto rxPool = new RestRoom();
for (int k = 0; k < nConnections; k++) {
auto sm = new RxSm(rxPool);
rxMachines ~= sm;
sm.run();
}

This rxMachines array is just for the purpose of holding references,
since references in linked list are not counted at all by GC.

Now everything works fine, no mystical crashes any more :)
(...and I am beginning to dislike GC even more than before)

But the question remained.
Not counting references in Slist - is that by design?

[Bug d/101692] Program crushes at unpredictable moment of time

2021-07-31 Thread zed at lab127 dot karelia.ru via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101692

--- Comment #4 from Eugene Zhiganov  ---

investigation continues...

--
'RX-98' deregistered 107 (esrc.Io)
   !!!  esrc.EventSource.~this() : esrc.Io (owner RX-97)
   this @ 0x7f845328b680<<< note addr
   !!!  esrc.EventSource.~this() : esrc.Timer (owner RX-97)
   this @ 0x7f845328b6c0
___!!!___edsm.StageMachine.~this(): RX-97 destroyed...

ecap.EventQueue.wait, n = 1, event @ 7FFDBCE6712C,
   event source @ 0x7f845328b680   <<<
  // this address is invalid, object already destroyed by GC
Segmentation fault
--

'RX-97' is a state machine instance.
RX machines are kept in a pool.
Slist is used as a stack/pool.
RX machines put themselves into the pool upon entering some state.

And it seems that since insertFront() method of Slist is not an
implicit assignment operator, D's GC does not count
reference in a list as a... reference. Oops.

Does it mean, it's impossible to store references in lists only?

[Bug d/101692] Program crushes at unpredictable moment of time

2021-07-31 Thread zed at lab127 dot karelia.ru via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101692

--- Comment #3 from Eugene Zhiganov  ---
I have reorginized my data - now references to EventSource class
and it's derivatives (timers, sockets, signals) are stored
in explicitly named data members of other classes.

That did not help, still crashes.

Then I added destructor for EventSource class to see,
if it is called or not. And it is...

sample output of a program...
-
'RX-0 @ IDLE' got 'M1' from 'CLIENT-2'
rx.RxSm.rxIdleM1 : fd = 12
'RX-0' registered 12 (esrc.Io)

!!! esrc.EventSource.~this() : esrc.ClientSocket // call of the destructor
!!! esrc.EventSource.~this() : esrc.Timer// call of the destructor

'RX-0 @ IDLE' got 'M0' from 'SELF'
'RX-0' enabled 12 (esrc.Io, oneshot)
ecap.EventQueue.wait, n = 1, event @ 7FFE506B486C
ecap.EventQueue.wait, n = 1, event @ 7FFE506B486C, event source @ 7FB726991F40
Segmentation fault (core dumped)


So now I understand, why the crash is happening -
an object reference, obtained from epoll_wait()
is invalid, because the object was already removed by GC.

But I do not understand, why GC destructs these objects...

[Bug d/101692] Program crushes at unpredictable moment of time

2021-07-31 Thread zed at lab127 dot karelia.ru via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101692

--- Comment #2 from Eugene Zhiganov  ---

I've attached full source, just in case.
And I think, I began to understand, what is wrong with it.

In brief: it looks like GC deallocates objects,
which it should not deallocate, because
it does not take into account for references,
which are stored in associative arrays.

[Bug d/101692] Program crushes at unpredictable moment of time

2021-07-31 Thread zed at lab127 dot karelia.ru via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101692

--- Comment #1 from Eugene Zhiganov  ---
Created attachment 51227
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51227=edit
references to objects in associative arrays