[tor-bugs] #30122 [Core Tor/Stem]: Make stem's unit tests propagate the backtrace signals to child processes

[Tor Bug Tracker & Wiki]

#30122: Make stem's unit tests propagate the backtrace signals to child processes
-----------------------------------+------------------------------
 Reporter:  teor                   |          Owner:  teor
     Type:  enhancement            |         Status:  needs_review
 Priority:  Medium                 |      Milestone:
Component:  Core Tor/Stem          |        Version:
 Severity:  Normal                 |     Resolution:
 Keywords:  tor-ci-fail-sometimes  |  Actual Points:  0.4
Parent ID:  #29437                 |         Points:  0.5
 Reviewer:                         |        Sponsor:
-----------------------------------+------------------------------
Changes (by teor):

 * status:  needs_information => needs_review


Comment:

 Replying to [comment:2 atagar]:
 > Hi teor. Moving over from irc...
 >
 > {{{
 > 20:56 <+atagar> teor4: Hi teor. Concerning the 'ignore signals while
 >   in a signal handler' part of your stem signaling patch could you
 >   please provide repro steps for a case in which the
 disable_signal_handlers()
 >   call is helpful? I just tried sending SIGUSR1s both with and without
 >   doing that and in practice the dumps seem to have the same stacktraces
 >   but I probably simply need to adjust what I'm doing somehow.
 > }}}

 Signals are delivered asynchronously, so it is possible to have a signal
 arrive while python is executing a signal handler. Ignoring signals in a
 signal handler is a standard Unix precaution against these kinds of race
 conditions.

 From the Python documentation:

     Although Python signal handlers are called asynchronously as far as
 the Python user is concerned, they can only occur between the “atomic”
 instructions of the Python interpreter. This means that signals arriving
 during long calculations implemented purely in C (such as regular
 expression matches on large bodies of text) may be delayed for an
 arbitrary amount of time.

 https://docs.python.org/2/library/signal.html#module-signal

 For more information, see:

 https://en.wikipedia.org/wiki/Unix_signal#Risks

 I'm not sure if you can trigger a race condition with the current code. I
 wrote it carefully, so the outcome of each line (and most expressions)
 wouldn't be affected by multiple signals. But you can definitely get
 different stack traces, if the timing is just right.

 If you want to simulate a race condition, you can patch the pull request
 to signal the process itself:

 {{{
 -  # propagate the signal to any multiprocessing children
 -  pgid = os.getpgid(pid)
 -  for p in multiprocessing.active_children():
 -    # avoid race conditions
 -    if p.is_alive():
 -      os.kill(p.pid, sig)
 +  import time
 +  for _ in range(0, 10):
 +    # cause a race condition by repeating the signal to this process
 +    os.kill(pid, sig)
 +  # now keep the stack around, so it appears in future traces
 +  time.sleep(5)
 }}}

 Or you can just add a time.sleep(10) somewhere in the signal handler,
 after it prints the stack trace and flushes the buffer.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30122#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online