Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 25 Mar 2017 13:34:12 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-ports-bugs@FreeBSD.org
Subject:   [Bug 212607] devel/gdb: debugging threaded process broken
Message-ID:  <bug-212607-13-lJrauOQzdt@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-212607-13@https.bugs.freebsd.org/bugzilla/>
References:  <bug-212607-13@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212607

--- Comment #15 from commit-hook@freebsd.org ---
A commit references this bug:

Author: badger
Date: Sat Mar 25 13:33:25 UTC 2017
New revision: 315949
URL: https://svnweb.freebsd.org/changeset/base/315949

Log:
  MFC r313992, r314075, r314118, r315484:

  r315484:
      ptrace_test: eliminate assumption about thread scheduling

      A couple of the ptrace tests make assumptions about which thread in a
      multithreaded process will run after a halt. This makes the tests less
      portable across branches, and susceptible to future breakage. Instead,
      twiddle thread scheduling and priorities to match the tests'
      expectation.

  r314118:
      Actually fix buildworlds other than i386/amd64/sparc64 after r313992

      Disable offending test for platforms without a userspace visible
      breakpoint().

  r314075:
      Fix world build for archs where __builtin_debugtrap() does not work.

      The offending code was introduced in r313992.

  r313992:
      Defer ptracestop() signals that cannot be delivered immediately

      When a thread is stopped in ptracestop(), the ptrace(2) user may requ=
est
      a signal be delivered upon resumption of the thread. Heretofore, those
signals
      were discarded unless ptracestop()'s caller was issignal(). Fix this =
by
      modifying ptracestop() to queue up signals requested by the ptrace us=
er
that
      will be delivered when possible. Take special care when the signal is
SIGKILL
      (usually generated from a PT_KILL request); no new stop events should=
 be
      triggered after a PT_KILL.

      Add a number of tests for the new functionality. Several tests were
authored
      by jhb.

  PR:           212607
  Sponsored by: Dell EMC

Changes:
_U  stable/10/
  stable/10/sys/kern/kern_fork.c
  stable/10/sys/kern/kern_sig.c
  stable/10/sys/kern/kern_thr.c
  stable/10/sys/kern/subr_syscall.c
  stable/10/sys/kern/sys_process.c
  stable/10/sys/sys/signalvar.h
  stable/10/tests/sys/kern/Makefile
  stable/10/tests/sys/kern/ptrace_test.c
_U  stable/11/
  stable/11/sys/kern/kern_fork.c
  stable/11/sys/kern/kern_sig.c
  stable/11/sys/kern/kern_thr.c
  stable/11/sys/kern/subr_syscall.c
  stable/11/sys/kern/sys_process.c
  stable/11/sys/sys/signalvar.h
  stable/11/tests/sys/kern/Makefile
  stable/11/tests/sys/kern/ptrace_test.c

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-212607-13-lJrauOQzdt>