Opened 3 years ago

Closed 3 years ago

#22565 closed defect (not a bug)

Refactor tor's signal handler to avoid undefined behaviour

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: 0.3.2.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: memory-safety, technical-debt
Cc: Actual Points:
Parent ID: Points: 2
Reviewer: Sponsor:


A signal handler can be called at any time, including when Tor's data structures are in an inconsistent state.

The C standard says that setting anything other than a sig_atomic_t flag in a signal handler is undefined behaviour. POSIX is slightly more permissive, but we still do far too much in our signal handler.

Could we set flags and check them at the top of the event loop instead?
Or are there things we must handle right away?

Child Tickets

Change History (4)

comment:1 Changed 3 years ago by teor

We should declare these flags as volatile sig_atomic_t, set/increment them in the signal handler, and clear them in the main loop.

comment:2 Changed 3 years ago by nickm

Which signal handlers do you mean, exactly? Thanks to libevent, signal_callback() is not actually called from inside a signal handler; instead, it's called from within the mainloop, after the signal happens.

comment:3 Changed 3 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.3.2.x-final

comment:4 Changed 3 years ago by teor

Resolution: not a bug
Status: newclosed

Oh, right. I wax just reading process_signal(), without checking how it was called. Oops!

Note: See TracTickets for help on using tickets.