[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #30122 [Core Tor/Stem]: Make stem's unit tests propagate the backtrace signals to child processes
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs