Program crash: GC destroys an object unexpectedly

[Steven Schveighoffer]

On 9/23/21 1:44 PM, eugene wrote:
> On Thursday, 23 September 2021 at 17:20:18 UTC, Steven Schveighoffer wrote:
>> So imagine the sequence:
> 
> With ease!
> 
>> 1. ctrl-c, signal handler triggers, shutting down the loop
> 
> Just a note: there is no 'signal handler' in the program.
> SIGINT/SIGTERM are **blocked**, notifications (POLLIN) are received via 
> epoll_wait().

Oh interesting! I didn't read the code closely enough.

> 
>> 2. main exits
>> 3. GC finalizes all objects, including the Stopper and it's members
> 
> Probably, a destructor for Signal class should be added, in which
> 
> - close fd, obtained from signalfd()
> - unblock the signal (thus default signal handler is back again)

Yes, I would recommend that. Always good for a destructor to clean up 
any non-GC resources that haven't already been cleaned up. That's 
actually what class destructors are for.

> 
>> 4. ctrl-c happens again, but you didn't unregister the signal handler, 
>> so it's run again, referencing the now-deleted object.
> 
> At this point we have default signal handler
> 
>> 5. segfault
>> It's theoretically a very very small window.
> 
> But even without destructor, no segfault will happen,
> because **there is no signal handler**

So it gets written to the file descriptor instead? And nobody is there 
reading it, so it's just closed along with the process?

I've not done signals this way, it seems pretty clever and less prone to 
asynchronous issues.

-Steve