Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 06 Jan 2017 12:58: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@https.bugs.freebsd.org/bugzilla/>

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

            Bug ID: 215826
           Summary: C++ program signal handlers not called
           Product: Base System
           Version: CURRENT
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: misc
          Assignee: freebsd-bugs@FreeBSD.org
          Reporter: kami@freebsd.org
                CC: freebsd-amd64@FreeBSD.org
                CC: freebsd-amd64@FreeBSD.org

18 days ago I got a bug report for sysutils/powerdxx:
https://github.com/lonkamikaze/powerdxx/issues/3

There is some distracting content in the report, e.g. the OP misidentified =
an
unrelated ACPI problem as part of the problem he/she was reporting.

The issue to sum it up is, that (at least my) C++ programs don't get their
signal handlers called (that includes default signal handlers that I never
touched).

Affected are the `loadrec` and `powerd++` binaries. The `loadrec` binary do=
es
not touch signal handlers, so the default handlers stay in place.

I had a couple of people try to help me debug the issue and as far as we co=
uld
tell using truss and dtrace signals got sent, but the signal handlers just
don't get called. I don't know how to debug this further (how do you debug
something that is not happening?). But we found a workaround: link with
`-lpthread`. My assumption is that `pthread` replaces system functions with
thread safe versions and as a side effect replaces whatever got recently br=
oken
on CURRENT.

I documented this workaround in the Makefile of my project:
https://github.com/lonkamikaze/powerdxx/commit/2d80d990121802b4402cf54bc9a3=
28449ae8f326

I don't know when exactly it broke, I tested on head/r310361, the OP was
running head/r310173.

The problem occurs both if I include `signal(3)` via `<csignal>` or
`<signal.h>` or not at all (i.e. `loadrec`).

To reproduce get the last version without the workaround from the repo:
https://github.com/lonkamikaze/powerdxx/tree/93a755fbc4d7ec36e5a9d4a35d5a33=
052cc0e678

--=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>