Menu
▾
▴
check-devel
|
From: Ken M. <zar...@nt...> - 2020-05-22 02:51:21
|
I build check as part of linuxfromscratch, and I've been seeing these errors since February 2018, but apparently not everyone encounters them. I'm looking at a new approach to how we build the fresh system, and as part of that I'm trying to track down why any remaining test failures that I encounter are happening. So, I'm keen to understand what is different about my builds. The logs are "somewhat large", so I assume the mailing list will not accept them. Uploaded to http://www.linuxfromscratch.org/~ken/check_test_errors/ I can see that each of these failing tests reports 43 errors, but I'm none the wiser about which items in the log are the actual errors. These logs are from building on a completed system built in March, with various normal hardening and optimization CFLAGS, but back in 2018 I didn't have those flags. All my builds are on x86_64. Any help will be appreciated. Thanks. ĸen -- Do you not know that, what you belittle by the name tree is but the mere four-dimensional analogue of a whole multidimensional universe which - no, I can see you do not. -- Druellae (a Dryad) |
|
From: <chr...@ma...> - 2020-05-22 05:13:42
|
I sent this already, but now I'm resending from an address already subscribed to the mailing list. Hi, Thanks for posting full logs. The following excerpts look like unexpected failures to me. I think it's some problem with forks and signals. However, it's been a while since I've looked at things closely, so don't take my word for it. Chris check_check.log --------------- Running suite(s): Fix Sub 0%: Checks: 1, Failures: 1, Errors: 0 check_check_fixture.c:36:S:Fix Sub:unchecked_setup:0: Test failure in fixture check.c:586: Bad status in set_fork_status Check Servant2 check_check_fixture.c:336:F:Core:test_ch_setup_sig:0: SRunner stat string incorrect with checked setup signal On 2020-05-21 19:51, Ken Moffat via Check-devel wrote: > I build check as part of linuxfromscratch, and I've been seeing > these errors since February 2018, but apparently not everyone > encounters them. I'm looking at a new approach to how we build the > fresh system, and as part of that I'm trying to track down why any > remaining test failures that I encounter are happening. > > So, I'm keen to understand what is different about my builds. The > logs are "somewhat large", so I assume the mailing list will not > accept them. Uploaded to > http://www.linuxfromscratch.org/~ken/check_test_errors/ > > I can see that each of these failing tests reports 43 errors, but > I'm none the wiser about which items in the log are the actual > errors. These logs are from building on a completed system built in > March, with various normal hardening and optimization CFLAGS, but > back in 2018 I didn't have those flags. All my builds are on > x86_64. > > Any help will be appreciated. Thanks. > > ĸen > |
|
From: <chr...@ma...> - 2020-05-27 19:36:04
|
On 2020-05-27 00:47, Branden Archer wrote: > (I do not seem to be getting all the emails from Ken for some reason. I > see some message I did not see in Fredrik's response.) My emails from Ken say "Ken Moffat via Check-devel", if there's an issue it's probably related to that. I'll forward them all in order. Ken, please reply-all if you aren't already, the mailing list won't send duplicate messages. > Perhaps the test needs to be updated to pick another signal to try. Or, > maybe inducing a division by zero is a portable way to cause a SIGFPE. Since Check is a C unit testing framework, we could assume that tested systems are compliant either with ISO C or a well-defined subset of ISO C, e.g. ISO C without forking. The POSIX-2017 spec refers to ISO C and is clear that raise(SIGFPE) is supposed to generate a signal: The ISO C standard only requires the signal names SIGABRT, SIGFPE, SIGILL, SIGINT, SIGSEGV, and SIGTERM to be defined. An implementation need not generate any of these six signals, except as a result of explicit use of interfaces that generate signals, such as raise(), [CX] [Option Start] kill(), the General Terminal Interface (see Special Characters), and the kill utility, unless otherwise stated (see, for example, XSH Memory Protection). https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html The C11 standard has the similar wording on page 283 (numbered as 265): http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf I'm not an expert in this area by any means. I'm most curious to know if Ken's observed behaviour is a bug or if his system is working as intended, and if so then why? Probably someone at gcc/clang/glibc/linux will know a lot more about this. Chris |
|
From: Ken M. <zar...@nt...> - 2020-05-24 05:46:07
|
On Thu, May 21, 2020 at 09:48:34PM -0700, chr...@ma... wrote:
> I sent this already, but now I'm resending from an address already
> subscribed to the mailing list.
>
Yeah, lists can be fun - that bit me too.
> Hi,
>
> Thanks for posting full logs.
>
> The following excerpts look like unexpected failures to me. I think it's
> some problem with forks and signals. However, it's been a while since I've
> looked at things closely, so don't take my word for it.
>
> Chris
>
> check_check.log
> ---------------
> Running suite(s): Fix Sub
> 0%: Checks: 1, Failures: 1, Errors: 0
> check_check_fixture.c:36:S:Fix Sub:unchecked_setup:0: Test failure in
> fixture
>
> check.c:586: Bad status in set_fork_status
> Check Servant2
>
> check_check_fixture.c:336:F:Core:test_ch_setup_sig:0: SRunner stat string
> incorrect with checked setup signal
>
Before I posted, I'd already tried with --disable-fork (no failures,
but obviously a lot fewer tests were actually run) and I didn't get
those messages. But I'm at a loss about how to determine what is
causing them. It looks as if
Check Servant2
19%: Checks: 260, Failures: 167, Errors: 43
means there were 43 unexpected errors, but deciphering testsuites
seems to be an art which I have not acquired. The suites for
different packages are all pretty different from each other - unless
an individual test reports an obvious error where I can see how the
expected result differs from what actually happened, and ideally get
some error message along the way, then it might as well all be
written in a language I can't read.
Thanks anyway.
ĸen
--
Remembering The People's Republic of Treacle Mine Road.
Truth! Justice! Freedom! Reasonably priced Love!
And a Hard-boiled Egg!
|
|
From: Ken M. <zar...@nt...> - 2020-05-27 22:12:40
|
On Wed, May 27, 2020 at 12:35:41PM -0700, chr...@ma... wrote: > On 2020-05-27 00:47, Branden Archer wrote: > > (I do not seem to be getting all the emails from Ken for some reason. I > > see some message I did not see in Fredrik's response.) > > My emails from Ken say "Ken Moffat via Check-devel", if there's an issue > it's probably related to that. I'll forward them all in order. Ken, please > reply-all if you aren't already, the mailing list won't send duplicate > messages. > I thought I was doing that, but I might have forgotten on some replies. If so, apologies. More likely is validation failures causing my mails to either be rejected (if so, I'll find out in a few days), or marked as spam. > > Perhaps the test needs to be updated to pick another signal to try. Or, > > maybe inducing a division by zero is a portable way to cause a SIGFPE. > > Since Check is a C unit testing framework, we could assume that tested > systems are compliant either with ISO C or a well-defined subset of ISO C, > e.g. ISO C without forking. > > The POSIX-2017 spec refers to ISO C and is clear that raise(SIGFPE) is > supposed to generate a signal: > > The ISO C standard only requires the signal names SIGABRT, SIGFPE, SIGILL, > SIGINT, SIGSEGV, and SIGTERM to be defined. An implementation need not > generate any of these six signals, except as a result of explicit use of > interfaces that generate signals, such as raise(), [CX] [Option Start] > kill(), the General Terminal Interface (see Special Characters), and the > kill utility, unless otherwise stated (see, for example, XSH Memory > Protection). > > https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html > > The C11 standard has the similar wording on page 283 (numbered as 265): > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf > > I'm not an expert in this area by any means. I'm most curious to know if > Ken's observed behaviour is a bug or if his system is working as intended, > and if so then why? Probably someone at gcc/clang/glibc/linux will know a > lot more about this. > > Chris At the moment it looks as if there is something odd going on in most of my systems (not sure if I mentioned here, but my athlon 200ge built with -O2 -march=native on gcc-9.2 works as expected, other machines don't). The build where glibc rejected -O0 was altered to use -O1 for glibc. It hasn't changed the results for sigfpe in bash's tests in chroot, and has not yet got to check, but I expect I'll need to continue until I can boot the system (to get rid of the host glibc underlying chroot) and retry check. Not hopeful, but need to try. Like many things, I think an answer may have been documented somewhere, but so far I've not found anything relevant. Meanwhile, thanks for the help in understanding why the check tests fail. ĸen -- Do you not know that, what you belittle by the name tree is but the mere four-dimensional analogue of a whole multidimensional universe which - no, I can see you do not. -- Druellae (a Dryad) |
|
From: Ken M. <zar...@nt...> - 2020-06-07 15:48:24
|
On Wed, May 27, 2020 at 11:12:30PM +0100, Ken Moffat wrote: > On Wed, May 27, 2020 at 12:35:41PM -0700, chr...@ma... wrote: > > On 2020-05-27 00:47, Branden Archer wrote: > (re attempts to raise sigfpe not succeeding) > At the moment it looks as if there is something odd going on in most > of my systems (not sure if I mentioned here, but my athlon 200ge > built with -O2 -march=native on gcc-9.2 works as expected, other > machines don't). > Finally got through a fresh build - on the system with detuned glibc I'd expected the tests to pass, but still both check and bash had sigfpe errors. I then tried running the check tests on my desktop (the host system with detuned glibc) and was surprised to find they too failed. Booted the new system, the tests passed. Gradually building the new system, running the check tests from time to time, all good. Completed enough to use startx - in the tty the tests passed, but in my term they again failed. Turns out I'v been looking in the wrong place: I use rxvt-unicode. Once I started to suspect that might be the problem, google found http://lists.schmorp.de/pipermail/rxvt-unicode/2013q3/001839.html and at the beginning of that thread is a link to the perl issue: https://github.com/Perl/perl5/issues/12349 In (embedded) perl, sigfpe doesn't get passed through. Thanks again for your assistance, ĸen -- +++ OUT OF CHEESE ERROR. REDO FROM START +++ |
|
From: Ken M. <zar...@nt...> - 2020-05-28 00:59:49
|
On Wed, May 27, 2020 at 11:12:30PM +0100, Ken Moffat via Check-devel wrote: (Adding Branden) > On Wed, May 27, 2020 at 12:35:41PM -0700, chr...@ma... wrote: > > On 2020-05-27 00:47, Branden Archer wrote: > > The build where glibc rejected -O0 was altered to use -O1 for glibc. > It hasn't changed the results for sigfpe in bash's tests in chroot, > and has not yet got to check, but I expect I'll need to continue > until I can boot the system (to get rid of the host glibc underlying > chroot) and retry check. Not hopeful, but need to try. > > Like many things, I think an answer may have been documented > somewhere, but so far I've not found anything relevant. > > Meanwhile, thanks for the help in understanding why the check tests > fail. > That new build has now been booted. I then built check and ran the tests - they all passed, so I did need to get away from the host glibc which was sitting under chroot. I think a -O1 build might be a bit slower than I like, and detuning from glibc's default of -O2 feels odd, but I guess I'm on the way forward and with a variety of things to try over the next week or so. Thanks again to you both! ĸen -- Do you not know that, what you belittle by the name tree is but the mere four-dimensional analogue of a whole multidimensional universe which - no, I can see you do not. -- Druellae (a Dryad) |
|
From: <chr...@ma...> - 2020-05-28 16:40:28
|
On 2020-05-27 17:59, Ken Moffat via Check-devel wrote: > That new build has now been booted. I then built check and ran the > tests - they all passed, so I did need to get away from the host > glibc which was sitting under chroot. > > I think a -O1 build might be a bit slower than I like, and detuning > from glibc's default of -O2 feels odd, but I guess I'm on the way > forward and with a variety of things to try over the next week or > so. > > Thanks again to you both! Good news! You're welcome! I think if you want to pursue this it's either a bug in glibc because they're relying on undefined behaviour, or a bug in GCC because an optimization is unsound. If you do want to narrow it down, and get back most of your performance, you can make a list of optimization flags enabled by -O2 that aren't enabled by -O1, and then do a binary search for the offender. This would also be more useful information for a bug report. Of course, this might require some patience... Chris |
|
From: <chr...@ma...> - 2020-05-24 06:56:15
|
On 2020-05-23 22:45, Ken Moffat via Check-devel wrote: > On Thu, May 21, 2020 at 09:48:34PM -0700, chr...@ma... wrote: >> check_check_fixture.c:336:F:Core:test_ch_setup_sig:0: SRunner stat string >> incorrect with checked setup signal If you look at tests/check_check_fixture.c:336, it says in the comment at the top of the function that the test will fail without fork. > Before I posted, I'd already tried with --disable-fork (no failures, > but obviously a lot fewer tests were actually run) and I didn't get > those messages. More evidence that it's a fork issue on your system. Official advice is for you to use Check in --disable-fork mode. > But I'm at a loss about how to determine what is > causing them. It looks as if > > Check Servant2 > 19%: Checks: 260, Failures: 167, Errors: 43 > > means there were 43 unexpected errors, but deciphering testsuites > seems to be an art which I have not acquired. The suites for > different packages are all pretty different from each other - unless > an individual test reports an obvious error where I can see how the > expected result differs from what actually happened, and ideally get > some error message along the way, then it might as well all be > written in a language I can't read. I agree, it's hard to decipher our own testing logs. Without looking too hard, my guess is that these 43 errors are cascading failures that result from your system's fork not working properly. Ideally we would have some tests that check whether or not fork works, and then not run the tests that require fork to work. Or in other words, --disable-fork should be automatic if fork doesn't actually work. Assuming you still want to fix this, can you compile and run a simple program that relies on fork? Examples here: https://www.geeksforgeeks.org/fork-system-call/ Also, what does Check's configure say about fork? There's explicit testing in there. You can also look at config.log. If that all works fine, then you can start testing the other functions related to fork that Check uses. They'll all show up in https://linux.die.net/man/7/signal - src/check_run.c is a good starting point to look for them. An alternatively useful thing would be a test in configure.ac that forced --disable-fork if fork (or a related signal function) was not working. Good luck! Chris |
|
From: Branden A. <b.m...@gm...> - 2020-05-24 18:21:56
|
Hi Ken.
Thanks for taking a look at the logs, Chris.
I'd like to give another look over the logs to see what may be amiss.
At a high level, the test-suite.log file indicates there are two binaries
which found at least one test failure, namely check_check and
check_check_export.
The tests in those binaries check various behaviours in Check, and confirm
that stuff that should work does and that Check is able to detect when test
failures occur (such as SIGSEGVs, etc). They run near identical tests. On
my system (OSX) these two binaries do pass, and the first few lines of logs
are the following:
$ tests/check_check_export
Running suite(s): Fork Sub
100%: Checks: 3, Failures: 0, Errors: 0
check_check_fork.c:38:P:Core:test_inc:0: Passed
check_check_fork.c:47:P:Core:test_nofork_sideeffects:0: Passed
check_check_fork.c:54:P:Core:test_nofork_pid:0: Passed
Running suite(s): Check Servant
Running suite(s):100%: Checks: 0, Failures: 0, Errors: 0
check.c:586: Bad status in set_fork_status
Check Servant2
14%: Checks: 241, Failures: 166, Errors: 41
Note that failures and errors are being reported. The first part of the log
(the lines above and the check_check_sub.c lines) are unit tests that try
Check's API and either intentionally pass or intentionally fail. For
example, this line
check_check_sub.c:190:F:Simple Tests:test_ck_abort_msg:0: Failure expected
attempts to invoke a failure with a specific message. Later on in the tests
there are "test on the tests" (the check_check_master.c lines). These
confirm that the tests which were run report success/failure as expected,
the failure line number match, error messages match, etc. The test which
check the error messages start with:
check_check_master.c:679:P:Core Tests:test_check_all_msgs
and all those should report "Passed". I notice that there are two tests
which are not reporting the expected result:
check_check_master.c:746:F:Core Tests:test_check_all_msgs:179: For
test 179:Signal Tests:test_fpe expected 'Received signal 8 (Floating
point exception)', got 'Passed'
check_check_master.c:746:F:Core Tests:test_check_all_msgs:180: For
test 180:Signal Tests:test_mark_point expected 'Received signal 8
(Floating point exception)', got 'Shouldn't reach here'
Both of these failures are related to raising SIGFPE. Looking at the first
test, test_fpe:
START_TEST(test_fpe)
{
record_test_name(tcase_name());
record_failure_line_num(__LINE__-4); /* -4 as the failure is reported at
START_TEST() */
raise (SIGFPE);
}
Apparently on the system under test raise(SIGFPE) is either not causing a
signal or Check is not able to detect the signal. Other signals being
tested (such as SIGSEGV in test_segv) are being correctly detected.
The signal tests are only enabled with fork() is enabled. If fork() is
disabled the test will not be run, as it will not be relevant (e.g. Check
cannot detect signals unless the test are run from within their own
processes).
I suggest looking into an example program that raises a SIGFPE and
determining if it does cause a failure or not. For example. on my OSX
system:
Brandens-MBP:raise brarcher$ cat test.c
#include <stdio.h>
#include <signal.h>
int main() {
printf("Before\n");
raise(SIGFPE);
printf("After\n");
return 0;
}
Brandens-MBP:raise brarcher$ gcc test.c
Brandens-MBP:raise brarcher$ ./a.out
Before
Floating point exception: 8
Brandens-MBP:raise brarcher$
Hope it helps.
- Branden
On Sat, May 23, 2020 at 11:56 PM <chr...@ma...> wrote:
> On 2020-05-23 22:45, Ken Moffat via Check-devel wrote:
> > On Thu, May 21, 2020 at 09:48:34PM -0700, chr...@ma...
> wrote:
> >> check_check_fixture.c:336:F:Core:test_ch_setup_sig:0: SRunner stat
> string
> >> incorrect with checked setup signal
>
> If you look at tests/check_check_fixture.c:336, it says in the comment
> at the top of the function that the test will fail without fork.
>
> > Before I posted, I'd already tried with --disable-fork (no failures,
> > but obviously a lot fewer tests were actually run) and I didn't get
> > those messages.
>
> More evidence that it's a fork issue on your system. Official advice is
> for you to use Check in --disable-fork mode.
>
> > But I'm at a loss about how to determine what is
> > causing them. It looks as if
> >
> > Check Servant2
> > 19%: Checks: 260, Failures: 167, Errors: 43
> >
> > means there were 43 unexpected errors, but deciphering testsuites
> > seems to be an art which I have not acquired. The suites for
> > different packages are all pretty different from each other - unless
> > an individual test reports an obvious error where I can see how the
> > expected result differs from what actually happened, and ideally get
> > some error message along the way, then it might as well all be
> > written in a language I can't read.
>
> I agree, it's hard to decipher our own testing logs.
>
> Without looking too hard, my guess is that these 43 errors are cascading
> failures that result from your system's fork not working properly.
> Ideally we would have some tests that check whether or not fork works,
> and then not run the tests that require fork to work. Or in other
> words, --disable-fork should be automatic if fork doesn't actually work.
>
> Assuming you still want to fix this, can you compile and run a simple
> program that relies on fork? Examples here:
>
> https://www.geeksforgeeks.org/fork-system-call/
>
> Also, what does Check's configure say about fork? There's explicit
> testing in there. You can also look at config.log.
>
> If that all works fine, then you can start testing the other functions
> related to fork that Check uses. They'll all show up in
> https://linux.die.net/man/7/signal - src/check_run.c is a good starting
> point to look for them.
>
> An alternatively useful thing would be a test in configure.ac that
> forced --disable-fork if fork (or a related signal function) was not
> working.
>
> Good luck!
>
> Chris
>
>
> _______________________________________________
> Check-devel mailing list
> Che...@li...
> https://lists.sourceforge.net/lists/listinfo/check-devel
>
|
|
From: <chr...@ma...> - 2020-05-25 17:15:48
|
[Resending, again.] This is a much better analysis, Branden, thank you. On 2020-05-24 11:21, Branden Archer wrote: > I notice that there are two tests > which are not reporting the expected result: > > check_check_master.c:746:F:Core Tests:test_check_all_msgs:179: For test 179:Signal Tests:test_fpe expected 'Received signal 8 (Floating point exception)', got 'Passed' > check_check_master.c:746:F:Core Tests:test_check_all_msgs:180: For test 180:Signal Tests:test_mark_point expected 'Received signal 8 (Floating point exception)', got 'Shouldn't reach here' It would be good if there was a way to filter the logs and show only the problematic test results. The simplest method would be to save a known good testing log, and then do something like: $ diff expected.log test_results.log | grep -E '^\-|^+' Chris |
|
From: Ken M. <zar...@nt...> - 2020-05-26 17:09:35
|
On Sun, May 24, 2020 at 11:21:34AM -0700, Branden Archer wrote:
> Hi Ken.
>
Hi Branden,
it's taken me a little while to get back to this, but here we go:
> Thanks for taking a look at the logs, Chris.
>
> I'd like to give another look over the logs to see what may be amiss.
>
[...]
>
> and all those should report "Passed". I notice that there are two tests
> which are not reporting the expected result:
>
> check_check_master.c:746:F:Core Tests:test_check_all_msgs:179: For
> test 179:Signal Tests:test_fpe expected 'Received signal 8 (Floating
> point exception)', got 'Passed'
> check_check_master.c:746:F:Core Tests:test_check_all_msgs:180: For
> test 180:Signal Tests:test_mark_point expected 'Received signal 8
> (Floating point exception)', got 'Shouldn't reach here'
>
>
> Both of these failures are related to raising SIGFPE. Looking at the first
> test, test_fpe:
>
>
> START_TEST(test_fpe)
>
> {
>
> record_test_name(tcase_name());
>
> record_failure_line_num(__LINE__-4); /* -4 as the failure is reported at
> START_TEST() */
>
> raise (SIGFPE);
>
> }
>
>
> Apparently on the system under test raise(SIGFPE) is either not causing a
> signal or Check is not able to detect the signal. Other signals being
> tested (such as SIGSEGV in test_segv) are being correctly detected.
>
While going through the details of my other package tests in this
build, I noticed that bash seemed to be failing because it didn't
SIGFPE. ...
> The signal tests are only enabled with fork() is enabled. If fork() is
> disabled the test will not be run, as it will not be relevant (e.g. Check
> cannot detect signals unless the test are run from within their own
> processes).
>
> I suggest looking into an example program that raises a SIGFPE and
> determining if it does cause a failure or not. For example. on my OSX
> system:
>
> Brandens-MBP:raise brarcher$ cat test.c
>
> #include <stdio.h>
>
> #include <signal.h>
>
>
> int main() {
>
> printf("Before\n");
>
> raise(SIGFPE);
>
> printf("After\n");
>
> return 0;
>
> }
>
> Brandens-MBP:raise brarcher$ gcc test.c
>
> Brandens-MBP:raise brarcher$ ./a.out
>
> Before
>
> Floating point exception: 8
>
> Brandens-MBP:raise brarcher$
>
>
> Hope it helps.
>
> - Branden
>
Using that program:
ken@plexi ~/check-debug $vim test.c
ken@plexi ~/check-debug $gcc test.c
ken@plexi ~/check-debug $./a.out
Before
After
So I am indeed not getting that signal.
However, if I change the program to do a division by zero
ken@plexi ~/check-debug $diff -u test.c divbyzero.c
--- test.c 2020-05-26 17:48:11.655277178 +0100
+++ divbyzero.c 2020-05-26 17:59:22.661766358 +0100
@@ -5,13 +5,18 @@
int main() {
+ int a = 1000;
+ int z = 0;
+ int result;
+
printf("Before\n");
- raise(SIGFPE);
+ //raise(SIGFPE);
+ result = a / z;
printf("After\n");
- return 0;
+ return result;
}
I get the exception -
ken@plexi ~/check-debug $./divbyzero
Before
Floating point exception
So, raise on its own apparently doesn't generate the exception.
ĸen
--
Do you not know that, what you belittle by the name tree is but the
mere four-dimensional analogue of a whole multidimensional universe
which - no, I can see you do not. -- Druellae (a Dryad)
|
|
From: <chr...@ma...> - 2020-05-26 19:46:17
|
On 2020-05-26 10:09, Ken Moffat via Check-devel wrote:
> So, raise on its own apparently doesn't generate the exception.
Well, raise returns zero on success, so try:
printf("raise: %d\n", raise(SIGFPE))
Raise can be implemented by kill, so try:
printf("kill: %d\n", kill(getpid(), SIGFPE))
Try a -O0 build of glibc and then linux. I'm suggesting this because
you also noticed problems in Bash.
Chris
|
|
From: Ken M. <zar...@nt...> - 2020-05-26 20:49:58
|
On Tue, May 26, 2020 at 12:46:01PM -0700, chr...@ma... wrote:
> On 2020-05-26 10:09, Ken Moffat via Check-devel wrote:
> > So, raise on its own apparently doesn't generate the exception.
>
> Well, raise returns zero on success, so try:
>
> printf("raise: %d\n", raise(SIGFPE))
>
> Raise can be implemented by kill, so try:
>
> printf("kill: %d\n", kill(getpid(), SIGFPE))
>
raise: 0
kill: 0
> Try a -O0 build of glibc and then linux. I'm suggesting this because you
> also noticed problems in Bash.
>
> Chris
Hmm, I lack available systems. Will see if I can do chroot builds
on another box, but will probably take more than a week (various
rebuilds of packages from source, even on old systems, are coming up
when firefox releases).
Later.
ĸen
--
Do you not know that, what you belittle by the name tree is but the
mere four-dimensional analogue of a whole multidimensional universe
which - no, I can see you do not. -- Druellae (a Dryad)
|
|
From: Ken M. <zar...@nt...> - 2020-05-27 04:19:28
|
On Tue, May 26, 2020 at 09:49:49PM +0100, Ken Moffat via Check-devel wrote: > On Tue, May 26, 2020 at 12:46:01PM -0700, chr...@ma... wrote: > > On 2020-05-26 10:09, Ken Moffat via Check-devel wrote: > > > Try a -O0 build of glibc and then linux. I'm suggesting this because you > > also noticed problems in Bash. > > > > Chris > I changed my CFLAGS for glibc (only) to -O0 -march=native but no can do: error: #error "glibc cannot be compiled without optimization" ĸen -- Do you not know that, what you belittle by the name tree is but the mere four-dimensional analogue of a whole multidimensional universe which - no, I can see you do not. -- Druellae (a Dryad) |
|
From: Branden A. <b.m...@gm...> - 2020-05-27 07:47:29
|
(I do not seem to be getting all the emails from Ken for some reason. I see some message I did not see in Fredrik's response.) >From Ken's experiment, it is interesting that a division by zero can raise a floating point signal but signal(SIGFPE) cannot. Maybe raise(SIGFPE) is not as good a test as we thought. There is at least one other platform where trying to raise(SIGFPE) also does not work exactly as planned (link <https://github.com/libcheck/check/issues/97>). Looking at the commit history to determine why SIGFPE, the test was added in the initial revision of Check (link <https://github.com/libcheck/check/commit/daf41f96162e36a7d31e42f93f833472ef99ee6e#diff-2e4afdbfd1b0a116126cb3022ac187b0R40>). If there was a reason, it may be lost to the sands of time. Perhaps the test needs to be updated to pick another signal to try. Or, maybe inducing a division by zero is a portable way to cause a SIGFPE. - Branden On Tue, May 26, 2020 at 9:19 PM Ken Moffat via Check-devel < che...@li...> wrote: > On Tue, May 26, 2020 at 09:49:49PM +0100, Ken Moffat via Check-devel wrote: > > On Tue, May 26, 2020 at 12:46:01PM -0700, chr...@ma... > wrote: > > > On 2020-05-26 10:09, Ken Moffat via Check-devel wrote: > > > > > Try a -O0 build of glibc and then linux. I'm suggesting this because > you > > > also noticed problems in Bash. > > > > > > Chris > > > I changed my CFLAGS for glibc (only) to -O0 -march=native but no can > do: > > error: #error "glibc cannot be compiled without optimization" > > ĸen > -- > Do you not know that, what you belittle by the name tree is but the > mere four-dimensional analogue of a whole multidimensional universe > which - no, I can see you do not. -- Druellae (a Dryad) > > > _______________________________________________ > Check-devel mailing list > Che...@li... > https://lists.sourceforge.net/lists/listinfo/check-devel > |
|
From: Chris P. <chr...@ma...> - 2020-05-27 22:08:56
|
On 2020-05-27 00:47, Branden Archer wrote: > (I do not seem to be getting all the emails from Ken for some reason. I > see some message I did not see in Fredrik's response.) > > From Ken's experiment, it is interesting that a division by zero can > raise a floating point signal but signal(SIGFPE) cannot. Maybe > raise(SIGFPE) is not as good a test as we thought. There is at least one > other platform where trying to raise(SIGFPE) also does not work exactly > as planned (link <https://github.com/libcheck/check/issues/97>). That bug report is complaining that raise(SIGFPE) works fine from a simple program under Cygwin but not when Check is using it. Whereas Ken cannot get a simple program to work under Linux. So Check is failing in both cases, but maybe the Cygwin case shouldn't be failing and Ken's case should be failing? If that bug was resolved it might help. I have a Cygwin system but I'm just too busy to do more than comment for the forseable future. (Hence my off-the-cuff answers...) Chris |
Thanks for helping keep SourceForge clean.
X