'make check' fails for a debug build

[mhoes]

Hi,

I get the following error when running 'make check' on Linux for a 'debug build':

$ configure --enable-debug --enable-getoptwrapper --enable-ipv6 --enable-cckd-bzip2 --enable-het-bzip2 --enable-object-rexx --enable-regina-rexx --enable-interlocked-access-facility-2=yes --enable-optimization=no

$ make check Making check in decNumber make[1]: Entering directory '/home/maarten/src/hyperion-topdir/x86_64/hyperion/decNumber' make[1]: Nothing to be done for 'check'. make[1]: Leaving directory '/home/maarten/src/hyperion-topdir/x86_64/hyperion/decNumber' Making check in m4 make[1]: Entering directory '/home/maarten/src/hyperion-topdir/x86_64/hyperion/m4' make[1]: Nothing to be done for 'check'. make[1]: Leaving directory '/home/maarten/src/hyperion-topdir/x86_64/hyperion/m4' Making check in util make[1]: Entering directory '/home/maarten/src/hyperion-topdir/x86_64/hyperion/util' make[1]: Nothing to be done for 'check'. make[1]: Leaving directory '/home/maarten/src/hyperion-topdir/x86_64/hyperion/util' Making check in html make[1]: Entering directory '/home/maarten/src/hyperion-topdir/x86_64/hyperion/html' make[1]: Nothing to be done for 'check'. make[1]: Leaving directory '/home/maarten/src/hyperion-topdir/x86_64/hyperion/html' Making check in man make[1]: Entering directory '/home/maarten/src/hyperion-topdir/x86_64/hyperion/man' make[1]: Nothing to be done for 'check'. make[1]: Leaving directory '/home/maarten/src/hyperion-topdir/x86_64/hyperion/man' Making check in . make[1]: Entering directory '/home/maarten/src/hyperion-topdir/x86_64/hyperion' make[1]: Leaving directory '/home/maarten/src/hyperion-topdir/x86_64/hyperion' Making check in crypto make[1]: Entering directory '/home/maarten/src/hyperion-topdir/x86_64/hyperion/crypto' make[1]: Nothing to be done for 'check'. make[1]: Leaving directory '/home/maarten/src/hyperion-topdir/x86_64/hyperion/crypto' ../../hyperion/tests/runtest -p .libs -d ../../hyperion/tests Files: ../../hyperion/tests/agf.tst ../../hyperion/tests/awsbsf.tst ../../hyperion/tests/bfp-001-divtoint.tst ../../hyperion/tests/bfp-002-loadr.tst ../../hyperion/tests/bfp-003-loadfpi.tst ../../hyperion/tests/bfp-004-cvttolog.tst ../../hyperion/tests/bfp-005-cvttolog64.tst ../../hyperion/tests/bfp-006-cvttofix.tst ../../hyperion/tests/bfp-007-cvttofix64.tst ../../hyperion/tests/bfp-008-cvtfrlog.tst ../../hyperion/tests/bfp-009-cvtfrlog64.tst ../../hyperion/tests/bfp-010-cvtfrfix.tst ../../hyperion/tests/bfp-011-cvtfrfix64.tst ../../hyperion/tests/bfp-012-loadtest.tst ../../hyperion/tests/bfp-013-comps.tst ../../hyperion/tests/bfp-014-divide.tst ../../hyperion/tests/bfp-015-sqrt.tst ../../hyperion/tests/bfp-016-add.tst ../../hyperion/tests/bfp-017-loadl.tst ../../hyperion/tests/bfp-018-subtract.tst ../../hyperion/tests/bfp-019-multiply.tst ../../hyperion/tests/bfp-020-multlonger.tst ../../hyperion/tests/bfp-021-multadd.tst ../../hyperion/tests/bfp-022-multsub.tst ../../hyperion/tests/cipher.tst ../../hyperion/tests/cmd-abs.tst ../../hyperion/tests/cmd-rv.tst ../../hyperion/tests/csxtr.tst ../../hyperion/tests/digest.tst ../../hyperion/tests/hetbsf.tst ../../hyperion/tests/ilc.tst ../../hyperion/tests/invpsw.tst ../../hyperion/tests/kimd-hw.tst ../../hyperion/tests/klmd-hw.tst ../../hyperion/tests/kmac-hw.tst ../../hyperion/tests/kmc-hw.tst ../../hyperion/tests/kmctr-hw.tst ../../hyperion/tests/kmf-hw.tst ../../hyperion/tests/km-hw.tst ../../hyperion/tests/kmo-hw.tst ../../hyperion/tests/leapfrog.tst ../../hyperion/tests/logicimm.tst ../../hyperion/tests/mainsize.tst ../../hyperion/tests/mhi.tst ../../hyperion/tests/mvcle.tst ../../hyperion/tests/pfpo.tst ../../hyperion/tests/privop.tst ../../hyperion/tests/problem.tst ../../hyperion/tests/pr.tst ../../hyperion/tests/runtest0.tst ../../hyperion/tests/runtest4.tst ../../hyperion/tests/semipriv.tst ../../hyperion/tests/sigp.tst ../../hyperion/tests/ssk370.tst ../../hyperion/tests/sske370.tst ../../hyperion/tests/sske390.tst ../../hyperion/tests/sske.tst ../../hyperion/tests/stfl.tst ../../hyperion/tests/timeout.tst ../../hyperion/tests/wild.tst ../../hyperion/tests/zeos.tst Variable ptrsize is set to "8". Variable platform is set to "Linux". Novalue in /home/maarten/src/hyperion-topdir/hyperion/tests/redtest.rexx -- variable OKS 548 >>> Then oks = oks + 1 This is often caused by missing or misspelled Testcase Note that the verbs are case sensitive. E.g., testcase is not correct. 569 +++ signal value lets_get_a_traceback 406 +++ call test lastmsg.ix = rest, msgtype 'message mismatch. ' info , 'Want:' rest, 'Got: ' lastmsg.ix 216 +++ call msg 'Error' 145 +++ call order 55 +++ call procline l Error 16 running "/home/maarten/src/hyperion-topdir/hyperion/tests/redtest.rexx", line 569: Label not found Error 16.1: Label "LETS_GET_A_TRACEBACK" not found Makefile:2786: recipe for target 'check' failed make: *** [check] Error 240

[srorso]

Hi Maarten:

Can you post the alltests.out from this run to this issue. There are a couple of causes for this, and I may be able to find the failing .tst by reviewing that file. Feel free to peek yourself; a missing *Compare will create this traceback too.

(I'm out of pocket for a few days, so it may be Tuesday before I can come up with anything.)

Best Regards, Steve Orso

[mhoes]

Hi,

Here is my 'allTests.out'.

allTests.out.gz

[mhoes]

By the way, the same error occurred with Fish-Git's Hyperion version, and he was able to resolve the issue with this commit: https://github.com/Fish-Git/hyperion/commit/eec676d5fb3b50d5e9df369177dc8dca86f6c1ce which you may or may not want to take a look at.

[srorso]

Hi Maarten:

Looking at the posted allTests.out file, it appears that lines 1-122073 are prefixed with one of the following:

../../../hyperion
../../hyperion/ar
../../hyperion/aw
../../hyperion/ch
../../hyperion/cm
../../hyperion/co
../../hyperion/cp
../../hyperion/he
../../hyperion/ho
../../hyperion/hs
../../hyperion/im
../../hyperion/lo
../../hyperion/sc
../../hyperion/ta
../../hyperion/ti
../../hyperion/ve

There does not appear be any code in redtest.rexx to handle these prefixes, so lines containing them are ignored. The prefixes stop at line 122074, after the Testcase directive for mainsize.tst and at the msglevel -debug command. So redtest.rexx, not "seeing" the Testcase, stops with the messages you see.

msglevel debug should cause error messages to be prefixed with a c module name and line number, and redtest.rexx is programmed to see those and skip past them when processing allTests.out. But the output from msglevel debug appears to include a relative path name and is truncated before the line number.

../../hyperion/ar could be ../../hyperion/archlvl.c if truncation is occuring.
../../hyperion/ti could be ../../hyperion/timer.c likewise.

I can continue to look at this early in the coming week.

Best Regards, Steve Orso

[srorso]

Hi Maarten:

This issue is specific to open source builds, at least on your distro and on Debian 8.6 64-bit. Windows builds are not affected. It occurs only when msglevel debug is in effect, either as a result of a debug build or a msglevel debug Hercules command.

While there may be an opportunity to improve redtest.rexx error reporting, the root cause is not there.

HHC01603I loadcore "../../hyperion/tests/bfp-001-divtoint.core"
HHC02250I Loading file ../../hyperion/tests/bfp-001-divtoint.core to location 0
HHC02249I Operation complete
HHC01603I msglevel debug
/home/srorso/Herc HHC17012I MSGLEVEL = verbose debug noemsgloc
/home/srorso/Herc HHC90000D DBG: RC = 0
/home/srorso/Herc HHC02336I Script 1: test: test starting
/home/srorso/Herc HHC02339I Script 1: test: duration limit: 1.000000 seconds
/home/srorso/Herc HHC02228I restart key pressed
/home/srorso/Herc HHC02333I Script 1: test: running...

Best Regards, Steve Orso

[mhoes]

Hi,

Thanks for the update. By the way, I had the exact same issue for Fish-Git's Hyperion version. Only on Linux, only for 'out-of-source' builds, and only for debug builds. He was able to fix the issue in his version with the following commit: https://github.com/Fish-Git/hyperion/commit/eec676d5fb3b50d5e9df369177dc8dca86f6c1ce

Perhaps you could take a look at that to see if it fixes the issue for 'Official' Hyperion too ?

Thanks.

[ivan-w]

On 2/23/2017 4:28 PM, mhoes wrote:

Hi,

Thanks for the update. By the way, I had the exact same issue for Fish-Git's Hyperion version. Only on Linux, only for 'out-of-source' builds, and only for debug builds. He was able to fix the issue in his version with the following commit: Fish-Git@eec676d https://github.com/Fish-Git/hyperion/commit/eec676d5fb3b50d5e9df369177dc8dca86f6c1ce

Perhaps you could take a look at that to see if it fixes the issue for 'Official' Hyperion too ?

... Errrm... Hyperion is no more official than any fork (the only actual official version is Roger's Spinhawk)....

[mhoes]

Alright, perhaps my particular choice of words was wrong. My apologies. I was merely trying to differentiate between:

'this version': https://github.com/hercules-390/hyperion and 'that version': https://github.com/fish-git/hyperion

From now on forward I will no longer use the term 'official' when speaking about 'Hyperion', but refer to them as 'this version' and 'that version'. ;)

But the point I was trying to make was that the issue was fully resolved in 'that version' by a specific commit, and that perhaps applying that same commit to 'this version' could solve it there as well.

[ivan-w]

On 2/23/2017 4:41 PM, mhoes wrote:

Alright, perhaps my particular choice of words was wrong. My apologies. I was merely trying to differentiate between:

'this version': https://github.com/hercules-390/hyperion and 'that version': https://github.com/fish-git/hyperion

From now on forward I will no longer use the term 'official' when speaking about 'Hyperion', but refer to them as 'this version' and 'that version'. ;)

But the point I was trying to make was that the issue was fully resolved in 'that version' by a specific commit, and that perhaps applying that same commit to 'this version' could solve it there as well.

I hear you..

But now, for example, for my QDIO/QETH fix, I have to track all the various forks, versions and whatnot to patch them as well...

This is getting out of hand.

--Ivan

[Fish-Git]

But now, for example, for my QDIO/QETH fix, I have to track all the various forks, versions and whatnot to patch them as well...

FWIW, your QDIO fix is in my Fish-Git fork, as are all recent commits to "this" Hyperion (except Mark's most recent Prepare for Read Subsystem Data commit; I'm still looking at it and will probably apply it to my fork slightly differently).

[Fish-Git]

This is getting out of hand.

I'm not convinced it's "out of hand" just yet. Yes, there are now multiple forks of Hyperion floating around (yours, mine, Roger's (and TK4- and a few others if you want to include them)),, but I don't think it's really any more than there were before we switched over to Git. They're just more visible now, whereas before they weren't.

As for me, I have never really concerned myself with Roger's 3.x series as I consider them his responsibility, not ours. That was after all the original intent: we make our changes to our (now your) 4.0 Hyperion repository and he picks and chooses which changes to incorporate into his.

Same goes with yours with respect to commits made to mine and vice versa.

My suggestion is to choose whichever one of them you're most interested in supporting (the one/ones you're most interested in contributing to) and let those responsible for the others worry about their own.

I guess what I'm saying is, the fact that there are multiple Hercules forks floating around is really not as big of a deal as you seem to want to make it out to be. <shrug>

[ivan-w]

On 2/23/2017 5:09 PM, Fish-Git wrote:

This is getting out of hand.

I'm not convinced it's "out of hand" just yet. Yes, there are now multiple forks of Hyperion floating around (yours, mine,

Fish,

I don't "have" a fork, nor any preferred "fork" (well, I have my own working local git repository(ies) on my machine.. But that doesn't count

• I don't have one on github or any public repository).

I usually commit my changes to the 'hyperion' fork because I have write access (for the time being) - and then hope other forks will pick it up (my commits are usually a few liners to a single file, and I usually post the patch as a diff in the bug tracking system, just in case).

But nope... Hyperion is not MY fork ! I just fix stuff I think need fixing for my own needs, and forward it to whoever wants to use that fix.

--Ivan

[srorso]

Hi Maarten:

Perhaps you could take a look at that to see if it fixes the issue for [this fork of] Hyperion too ?

Sure, and if you are in a hurry I will do that.

But I would rather gain the experience by researching the issue (I've already learned a bit more C and bunches more about Hercules). And there is an interaction between length of Hercules C file names and debug messages that can create this issue apart from my current line of research. In the current setup, a C source file name longer than 9 characters plus 2 for the ".c" (10 if the file is less than 1,000 lines) will trigger this too.

So let me know...

Best Regards, Steve Orso

[mhoes]

Hi,

I'm not in a hurry. I just thought that if there already might be a known solution to the problem, then it might be a good idea to try that first. But of course you can go research and find the solution yourself too, if you prefer that. (As if end-users could somehow make 'demands' on how volunteer developers choose to spend their spare time to begin with.)

[Fish-Git]

I don't "have" a fork, [...] But nope... Hyperion is not MY fork ! [...]

You misunderstand. My use of "your" was meant in the sense of "you guy's" (as in the current team of Hyperion developers). That's why I used the phrase: "we make our changes to our (now your) 4.0 Hyperion repository...". I am no longer an official developer. Thus the current Hyperion repository is no longer "mine" since I am no longer a member of the team.

You however, are still a part of that team. Thus current Hyperion is still "your" Hyperion.

I didn't mean to imply you had your own fork and apologize if I unintentionally conveyed that.

[mhoes]

Hi,

On Thu, Feb 23, 2017 at 8:44 PM, Fish-Git notifications@github.com wrote:

You misunderstand. My use of "your" was meant in the sense of "you guy's" (as in the current team of Hyperion developers). That's why I used the phrase: "we make our changes to our (now your) 4.0 Hyperion repository...". I am no longer an official developer. Thus the current Hyperion repository is no longer "mine" since I am no longer a member of the team.

I have been recently informed that one should not use the term 'official' when referring to versions of 'Hyperion'. Instead, they should from now on forwards be referred to as:

'this version': https://github.com/hercules-390/hyperion 'that version': https://github.com/fish-git/hyperion 'the other version': http://wotho.ethz.ch/tk4-/

More versions can be referenced to as 'the other, other version' and 'the other, other other version'.

;)

• Maarten

[ivan-w]

On 2/23/2017 8:44 PM, Fish-Git wrote:

You however, /are/ still a part of that team. Thus current Hyperion is still "your" Hyperion. I am not part of THAT team - it just happens the only github repository (that I know) to which I have write access.

--Ivan

[mhoes]

Hi,

On Thu, Feb 23, 2017 at 10:12 PM, Ivan Warren notifications@github.com wrote:

On 2/23/2017 8:44 PM, Fish-Git wrote:

You however, /are/ still a part of that team. Thus current Hyperion is still "your" Hyperion. I am not part of THAT team - it just happens the only github repository (that I know) to which I have write access.

--Ivan

Having write-access to a git repository 'officially' (there's that term again !) makes you 'part of the team'. ;)

• Maarten

[Fish-Git]

More versions can be referenced to as 'the other, other version' and 'the other, other other version'.

Okaaay.... :)

[Fish-Git]

I am not part of THAT team - it just happens the only github repository (that I know) to which I have write access.

I see...

Then please accept my apology, Ivan :)

[Fish-Git]

Having write-access to a git repository 'officially' (there's that term again !) makes you 'part of the team'.

That's what I thought too until just now. But apparently according to Ivan that's no longer true.

Sheesh. What a mess. :(

[mhoes]

Hi,

On Thu, Feb 23, 2017 at 11:42 PM, Fish-Git notifications@github.com wrote:

Having write-access to a git repository 'officially' (there's that term again !) makes you 'part of the team'.

That's what I thought too until just now. But apparently according to Ivan that's no longer true.

Sheesh. What a mess. :(

Well as far as my personal experience goes, 'open-source' projects (which the 'Q Public License' qualifies as, as far as I know), pretty much prefer to use 'technical' terms (perhaps because most developers are also some sort of technician, perhaps ?). And 'technically' speaking in this regard, as far as I can determine, boils down to: "can you add new code to the source code repository ? can you modify code in the repository ? can you undo modifications made by others in the repository ?" If the answer to that question is 'Yes', then you're part of the 'core developers' for that project, and therefore 'part of the team'. No 'mess' whatsoever as far as I can tell. All crystal clear.

• Maarten

[srorso]

Hi Maarten:

Changes committed; please give it a try and report your findings. Tested on Windows 10 MSVC and Debian GCC. The correction looks remarkably like Fish's, but the path was most educational. Thanks for your patience.

Best Regards, Steve Orso

[mhoes]

Hi,

On Fri, Feb 24, 2017 at 5:20 PM, Stephen Orso notifications@github.com wrote:

Changes committed; please give it a try and report your findings. Tested on Windows 10 MSVC and Debian GCC. The correction looks remarkably like Fish's, but the path was most educational. Thanks for your patience.

It works for me now, thanks !

• Maarten

[srorso]

Excellent. Thanks again for your patience.