4 Commits

Author SHA1 Message Date
Andrew Deason
1acc612687 tests: Avoid generating cores in softsig-helper
Our opr/softsig-t tests run softsig-helper to generate SIGSEGV and
SIGBUS signals (among other things), which may generate core files (if
'ulimit -c' is nonzero). The core files are useless, since we expect
those signals to be generated.

Usually the core files are generated in the build tree (where we run the
tests from), which is a minor annoyance. But some systems may be
configured to store core files in a central location (e.g.
/var/lib/systemd/coredump), which starts to build up over time after
many builds.

To avoid this, prevent core files from being generated in softsig-helper
for the SIGSEGV and SIGBUS cases by calling setrlimit().

Change-Id: Ice71e79009cf2b44d4cbe32233d3a7ee12e08d2d
Reviewed-on: https://gerrit.openafs.org/15795
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
2024-08-13 13:02:38 -04:00
Michael Meffie
8b2c4665aa tests: fix signo to signame lookup in opr/softsig tests
Fix the loop condition when scanning the signal number to name table to
convert a signal number to a name.  Instead of looping sizeof(size_t)
times, loop for the number of elements in the table.

This bug was masked on 64 bit-platforms, since the signal number to name
table table currently has 8 elements, which is coincidently the same as
sizeof(size_t) on 64-bit platforms.  The bug becomes apparent on 32-bit
systems; only the first 4 elements of the table are checked.

Example error output before this fix:

    $ cd tests
    $ ./libwrap ../lib ./runtests -o opr/softsig
    1..11
    ok 1
    ok 2
    ok 3
    ok 4
    ok 5
    not ok 6
    # Failed test in ./opr/softsig-t at line 57.
    # got: 'Received UNK
    # '
    # expected: 'Received TERM
    # '
    not ok 7
    # Failed test in ./opr/softsig-t at line 60.
    # got: 'Received UNK
    # '
    # expected: 'Received USR1
    # '
    not ok 8
    # Failed test in ./opr/softsig-t at line 63.
    # got: 'Received UNK
    # '
    # expected: 'Received USR2
    # '
    ok 9 - Helper exited on KILL signal.
    ok 10 - Helper exited on SEGV signal.
    ok 11 # skip Skipping buserror test; SIGBUS constant is not defined.
    # Looks like you failed 3 tests of 11.

Change-Id: I863cc9f3650c4a5e9ac9159d90e063b986a8460a
Reviewed-on: https://gerrit.openafs.org/12367
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
2016-12-16 15:20:39 -05:00
Michael Meffie
73e080cbb0 tests: fix typo in softsig test helper
Change-Id: I74183a04b54b70bf3593a53fdb5f164cbd6c3b98
Reviewed-on: http://gerrit.openafs.org/11893
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams <3chas3@gmail.com>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
2015-06-20 21:09:25 -04:00
Simon Wilkinson
cb0081604e opr: Add new softsig implementation
Signals and pthreaded applications are a poor match. OpenAFS has had
the softsig system (currently in src/util/softsig.c) in an attempt to
alleviate some of these problems. However, that implementation itself
has a number of problems. It uses signal functions that are unsafe in
pthreaded applications, and uses pthread_kill within its signal
handlers. Over the years it has been responsible for a number of
portability bugs.

The old implementation continues to receive signals in the main thread
of the application. However, the handler code is run within a seperate
signal handler thread. When the main thread receives a signal a stub
handler is invoked, which simply pthread_kill()s the signal handler
thread.

The new implementation simplifies things by only receiving signals in
the handler thread. It uses only pthread-compatible signal functions,
and invokes no code from within async signal handlers.

A complete test suite is supplied.

Change-Id: I4bac68c2f853f1e7578b54ddced3833a97dd3f82
Reviewed-on: http://gerrit.openafs.org/6947
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams <3chas3@gmail.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
2015-05-26 14:06:18 -04:00