Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 10 Jan 2017 19:27:12 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 215826] C++ program signal handlers not called
Message-ID:  <bug-215826-8-4EGG4dDss7@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-215826-8@https.bugs.freebsd.org/bugzilla/>
References:  <bug-215826-8@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=3D215826

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

Author: kib
Date: Tue Jan 10 19:26:55 UTC 2017
New revision: 311886
URL: https://svnweb.freebsd.org/changeset/base/311886

Log:
  Fix acquisition of nested write compat rtld locks.

  Obtaining compat rtld lock in write mode sets process signal mask to
  block all signals.  Previous mask is stored in the global variable
  oldsigmask.  If a lock is write-locked while another lock is already
  write-locked, oldsigmask is overwritten by the total mask and on the
  last unlock, all signals except traps appear to be blocked.

  Fix this by counting the write-lock nested level, and only storing to
  oldsigmask/restoring from it at the outermost level.

  Masking signals disables involuntary preemption for libc_r, and there
  could be no voluntary context switches in the locked code
  (dl_iterate_phdr(3) keeps a lock around user callback, but it was
  added long after libc_r was renounced).  Due to this, remembering the
  level in the global variable after the lock is obtained should be
  safe, because no two libc_r threads can acquire different write locks
  in parallel.

  PR:   215826
  Reported by:  kami
  Tested by:    yamagi@yamagi.org (previous version)
  To be reviewed by:    kan
  Sponsored by: The FreeBSD Foundation
  MFC after:    2 weeks

Changes:
  head/libexec/rtld-elf/rtld_lock.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-215826-8-4EGG4dDss7>