#695 Test failures on 3.1.2

[Luigi Baldoni]

Just to keep track of the problem.
On openSUSE Tumbleweed, the only way to build 3.1.2 and not fail any test is to build gnu-cobol without lto flags and by disabling hardening.

Otherwise #698 will fail with hardening and #984 will fail with lto.

See attached test logs.

[Simon Sobisch]

Test 984 "with lto" fails with:

+/tmp/ccJOu4v4.mk:1: *** missing separator. Stop.
+lto-wrapper: fatal error: make returned 2 exit status
+compilation terminated.
+/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld: error: lto-wrapper failed
+collect2: error: ld returned 1 exit status

If you can explain what that is about I can possibly say something else but so far it looks like your lto environment has a bug.

The other one is a theoretical bug in the testsuite source that could happen if the C routine defined there would be called without any parameter. It will be fixed to allow it be build without warnings "soon", if you want a clean build apply the following patch to the testsuite script:

    int      k,nargs,type,digits,scale,size,sign,byvalue;

-   cob_s64_t   val;
+   cob_s64_t   val = 0;
    char     *str;
    char     wrk[80],pic[30];   /* note: maxium _theoretical_ size */

    nargs = cob_get_num_params();
    printf ("CAPI called with %d parameters\n",nargs);

Thanks for the report, if you can give some insights about the lto error then we may could come up with a patch.

[Luigi Baldoni]

Test #698 is indeed fixed with that patch.

Regarding LTO problems, I must confess it's a tad beyond my comprehension: it's something I've seen happen multiple times and either lto is disabled for the package or upstream fixes it, but unfortunately I couldn't tell you how. I will inquire, though.

Meanwhile, does this mean anything to you?

[Simon Sobisch]

@lovigi - Can you please check if this is solved with 3.2?

The warning should be solved without any patch, the LTO - I guess you may tell me.

Note: Depending on the defaults it is "common" that one either has to explicit disable hardening (= auto-dropping everything related to that, which seems to have been done before) or explicit enable hardening (= auto-adding more flags during configure, which is in the current spec file), with the later considered "more safe but slower".

Side note: the spec file used with OpenSUSE may should be updated to use the official URLs:

URL:            https://www.gnu.org/software/gnucobol/
Source0:        https://ftp.gnu.org/gnu/gnucobol/gnucobol-%{version}.tar.xz
Source1:        https://ftp.gnu.org/gnu/gnucobol/gnucobol-%{version}.tar.xz.sig

(and I have no clue why there's a BuildRequires: dos2unix)

[Luigi Baldoni]

and I have no clue why there's a BuildRequires: dos2unix

Probably a leftover from when some text file was shipped with CRLF line endings.

I removed the patch above and reenabled LTO, logs attached.

P.S: I should add I'm not the package maintainer, I updated it only a couple of times.

[Simon Sobisch]

OK, there's one failure, and that is unrelated to LTO:

843. run_misc.at:14097: testing runtime check: write to internal storage (1) ...
./run_misc.at:14173: $COMPILE -fno-ec=program-arg-mismatch -fmemory-check=pointer caller.cob
./run_misc.at:14174: $COMPILE_MODULE -fno-ec=program-arg-mismatch callee.cob
./run_misc.at:14175: $COBCRUN_DIRECT ./caller
./run_misc.at:14179: $COMPILE -fno-ec=program-arg-mismatch -fmemory-check=using caller.cob
./run_misc.at:14180: $COBCRUN_DIRECT ./caller
/home/abuild/rpmbuild/BUILD/gnucobol-3.2/tests/testsuite.dir/at-groups/843/test-source: line 218:  2062 Segmentation fault      (core dumped) ( $at_check_trace; $COBCRUN_DIRECT ./caller ) >> "$at_stdout" 2>> "$at_stderr" 5>&-
--- -   2023-08-22 08:46:36.542710526 +0000
+++ /home/abuild/rpmbuild/BUILD/gnucobol-3.2/tests/testsuite.dir/at-groups/843/stderr   2023-08-22 08:46:36.536282771 +0000
@@ -1,2 +1,4 @@
-libcob: caller.cob:30: error: memory violation detected for 'var' after CALL
+
+caller.cob:30: attempt to reference invalid memory address (signal)
+

Note that this test explicit trash the memory to trigger a new check after the fact - but it seems that the specific system this test was run on the system was faster to detect that... (my Debian LTS doesn't catch that, also not when configured with --enable-hardening).

If someone could find a "less intrusive" stack breakage that the system does not catch, but GnuCOBOL does, that would be quite nice.
Until then you may want to disable the specific check by using the following somewhere between unpacking and running make check:

# work around "trash memory by design - catched by system before libcob"
sed -i tests/testsuite -e "/^843;/d";

If this (unportable) test is the only thing then it would definitely be good to update the package with the new settings and without a patch.

And I'd say we can close-fix this issue, do you agree?