Libelektra: optimizations-off + testshell_markdown_typechecker = unstable

[ingwinlu]

The recently introduced build task with optimizations disabled (#2048) seems to be unstable when it comes to testshell_markdown_typechecker.

It seems to timeout (5min of inactivity) every other run.

I have disabled ( 5ad86d4 ) the build task for now.

[markus2330]

@KurtMi any idea what is happening here?

[ingwinlu]

In the PR that added it it occured for the first time here:
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-2048/2/pipeline

I attributed the fail to our build servers as replaying it seemed to correct the issue in
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-2048/5/pipeline/339.
Interesting is that when it works it passes in 2s:

        Start 138: testshell_markdown_typechecker
171/221 Test #138: testshell_markdown_typechecker ...........   Passed    2.01 sec

[KurtMi]

@KurtMi any idea what is happening here?

No not really

[KurtMi]

But the old jenkins job succeed up to now? or was that job deactivated?

[ingwinlu]

Old job got deactivated when we ported it over to the new system.
It never failed, but that be due to it actually not running testshell_markdown_typechecker:
https://build.libelektra.org/jenkins/job/elektra-gcc-configure-debian-optimizations/299/consoleFull

[KurtMi]

Alright, but in the PR #2055 it worked the first time:
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-2055/10/pipeline/

[ingwinlu]

@KurtMi you think the changes in #2055 might contain a fix? because I can not spot anything that would affect the behaviour. I requested another build of #2055 to see if we can make it fail identically.

[KurtMi]

@KurtMi you think the changes in #2055 might contain a fix?

No, but it failed always the first time (or not?) and in #2055 not.

[ingwinlu]

No it is entirely random as far as i can tell. in master it passed the first time and failed from there on out till i disabled it.

[markus2330]

Are we sure that the problems are caused by turning off optimizations in the build?

If this is not the case, @KurtMi is not the right person :wink:

[KurtMi]

Well we might ask @e1528532 if he has any clue. I tried for the last hour to compile the typechecker plugin locally but I failed :)

[e1528532]

It might be related to the issue adressed in #2055 i try to get that merged today. If that doesn't help the PR #1944 also contains some more improvements that might help, and i am also working on it.
If neither of those helps i'll have to look further into it. I don't think the whole thing is that far from being stable anymore.

@KurtMi have you installed c2hs today or recently in order to compile it?

[KurtMi]

@KurtMi have you installed c2hs today or recently in order to compile it?

Yes, i followed the instructions from /src/bindings/haskell/README.md. I need to create a new local docker image I will retry it there!

[e1528532]

Yes, i followed the instructions from /src/bindings/haskell/README.md

@KurtMi I think thats the issue. A new version of language-c, which is a dependency of c2hs got releast on the 2nd june. Unfortunately if c2hs gets compiled with that version, it fails to build the typechecker plugin. With the previous language-c version 0.7.2 it seems to work.

So if you want to try it out locally, first ensure the previous version is removed with the command
ghc-pkg unregister language-c. Then install the previous version of language-c with the command cabal install language-c-0.7.2 and last reinstall c2hs with cabal install c2hs. In that case it should compile with that version. Now if you cleanup the previous build artifacts it should be able to compile it again.

Good point thought i have to add that to the readme as well!

@ingwinlu I think you issue might be fixed with the regexdispatcher PR where the typechecker doesn't use kdb inside a plugin anymore as that can cause hangups like your build experienced.

[KurtMi]

@ingwinlu it seems that the retrigger of PR-2055 also worked.
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-2055/11/pipeline

[e1528532]

Should be resolved with #2055 and #1944 .