Thanks Mark! Prior to this change, if you used userspace dtrace enough, eventually you would get a spurious SIGTRAP on a process, which has the default behavior of dumping core. Perhaps understandably, people balk at random core files lying around. Or at dtrace killing their programs. This patch should address that long-standing problem.
An easy repro scenario was described in the differential: > It's possible to reproduce this by, for example, calling strlen() > in a loop, probing every instruction in strlen(), and killing dtrace(1). On Thu, Feb 21, 2019 at 2:54 PM Mark Johnston <ma...@freebsd.org> wrote: > > Author: markj > Date: Thu Feb 21 22:54:17 2019 > New Revision: 344452 > URL: https://svnweb.freebsd.org/changeset/base/344452 > > Log: > Fix a tracepoint lookup race in fasttrap_pid_probe(). > > fasttrap hooks the userspace breakpoint handler; the hook looks up the > breakpoint address in a hash table of tracepoints. It is possible for > the tracepoint to be removed by a different thread in between the > breakpoint trap and the hash table lookup, in which case SIGTRAP gets > delivered to the target process. Fix the problem by adding a > per-process generation counter that gets incremented when a tracepoint > belonging to that process is removed. Then, when a lookup fails, the > trapping instruction is restarted if the thread's counter doesn't match > that of the process. _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
