#31614: Implement clean_up_backtrace_handler() -------------------------------------------------+------------------------- Reporter: teor | Owner: teor Type: defect | Status: | needs_revision Priority: Medium | Milestone: Tor: | 0.4.2.x-final Component: Core Tor/Tor | Version: Tor: | 0.3.5.1-alpha Severity: Normal | Resolution: Keywords: consider-backport-after-042-stable, | Actual Points: 0.2 consider-backport-if-needed, diagnostics, | 042-should, 035-backport-maybe, 040-backport- | maybe, 041-backport-maybe, regression, | BugSmashFund | Parent ID: | Points: 0.2 Reviewer: dgoulet | Sponsor: -------------------------------------------------+-------------------------
Comment (by teor): You're right, there are a bunch of nasty race conditions here. This is what we need to fix: 1. Always lock the mutex before using cb_buf (there are some places where we don't do this) 2. Lock the mutex before adding or removing signal handlers (might not be strictly required, but it makes reasoning about locks easier) 3. Abort if destroying the mutex fails (doesn't save us from undefined behaviour, but does notify us when it happens) We could also 4. Lock a mutex before logging anywhere in the err module (this could cause more issues than it solves) The best way to do this might be to put cb_buf in its own file, and use accessor functions. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/31614#comment:11> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs