[LLVM backend regression] RuntimeError: unreachable

[buu700]

I just had to rebuild sidh.js with latest-fastcomp to work around an error caused by latest-upstream.

With the following test case:

git clone https://github.com/cyph/sidh.js
cd sidh.js
make
node -e "require('./dist/sidh').keyPair().then(kp => console.log(kp))"

The make succeeds, but then I get the following unexpected run-time error:

RuntimeError: unreachable
RuntimeError: unreachable

/cyph/dist/sidh.js:1
var sidh=function(){var A,I,g,B,C={};function Q(A,I){if(0===A)return I;throw new Error("SIDH error: "+A)}function i(A,I){return new Uint8Array(new Uint8Array(C.HEAPU8.buffer,A,I))}function E(A){try{C._free(A)}catch(A){setTimeout((function(){throw A}),0)}}C.ready=new Promise((function(A,I){(B={}).onAbort=I,B.onRuntimeInitialized=function(){try{B._sidhjs_public_key_bytes(),A(B)}catch(A){I(A)}};var g,B=void 0!==B?B:{},C={};for(g in B)B.hasOwnProperty(g)&&(C[g]=B[g]);var Q=[],i=!1,E=!1,o=!1,a=!1,G=!1;i="object"==typeof window,E="function"==typeof importScripts,a="object"==typeof process&&"object"==typeof process.versions&&"string"==typeof process.versions.node,o=a&&!i&&!E,G=!i&&!o&&!E;var n,r,c,t,D="";function e(A){return B.locateFile?B.locateFile(A,D):D+A}o?(D=__dirname+"/",n=function(A,I){var g;return(g=YA(A))||(c||(c=eval("require")("fs")),t||(t=eval("require")("path")),A=t.normalize(A),g=c.readFileSync(A)),I?g:g.toString()},r=function(A){var I=n(A,!0);return I.buffer||(I=new Uint8Array(
abort(RuntimeError: unreachable). Build with -s ASSERTIONS=1 for more info.

This problem goes away after running emsdk install latest-fastcomp ; emsdk activate latest-fastcomp ; make.

[paulocoutinhox]

My stacktrace:

index.js:77 Uncaught RuntimeError: unreachable
    at pdfium::base::AllocPages(void*, unsigned long, unsigned long, pdfium::base::PageAccessibilityConfiguration, pdfium::base::PageTag, bool) (index.wasm:0x71085)
    at pdfium::base::internal::PartitionBucket::SlowPathAlloc(pdfium::base::internal::PartitionRootBase*, int, unsigned long, bool*) (index.wasm:0x72900)
    at fxcrt::StringDataTemplate<char>::Create(unsigned long) (index.wasm:0x5628)
    at fxcrt::StringDataTemplate<char>::Create(char const*, unsigned long) (index.wasm:0x5695)
    at fxcrt::ByteString::ByteString(char const*) (index.wasm:0x886e)
    at CLinuxPlatform::CreateDefaultSystemFontInfo() (index.wasm:0xf501)
    at CFX_GEModule::Create(char const**) (index.wasm:0x13666)
    at FPDF_InitLibraryWithConfig (index.wasm:0x70a9e)
    at main (index.wasm:0x367b)
    at index.js:1591
$pdfium::base::AllocPages(void*, unsigned long, unsigned long, pdfium::base::PageAccessibilityConfiguration, pdfium::base::PageTag, bool) @ index.wasm:0x71085
$pdfium::base::internal::PartitionBucket::SlowPathAlloc(pdfium::base::internal::PartitionRootBase*, int, unsigned long, bool*) @ index.wasm:0x72900
$fxcrt::StringDataTemplate<char>::Create(unsigned long) @ index.wasm:0x5628
$fxcrt::StringDataTemplate<char>::Create(char const*, unsigned long) @ index.wasm:0x5695
$fxcrt::ByteString::ByteString(char const*) @ index.wasm:0x886e
$CLinuxPlatform::CreateDefaultSystemFontInfo() @ index.wasm:0xf501
$CFX_GEModule::Create(char const**) @ index.wasm:0x13666
$FPDF_InitLibraryWithConfig @ index.wasm:0x70a9e
$main @ index.wasm:0x367b
(anonymous) @ index.js:1591
callMain @ index.js:5933
doRun @ index.js:5990
(anonymous) @ index.js:6001
setTimeout (async)
run @ index.js:5997
runCaller @ index.js:5911
removeRunDependency @ index.js:1520
receiveInstance @ index.js:1680
receiveInstantiationResult @ index.js:1697
Promise.then (async)
(anonymous) @ index.js:1726
Promise.then (async)
instantiateAsync @ index.js:1723
createWasm @ index.js:1754
(anonymous) @ index.js:5465

[paulocoutinhox]

I tried version 3.0.0 and the problem still :(

[buu700]

I ended up solving the problem in my project. It turned out that two different C files were defining slightly different versions of a particular function (one was void while the other returned an int status code).

The original fastcomp implementation apparently worked around the problem, while the LLVM backend for whatever reason handles it less gracefully. This may or may not have been the case at the time I opened the issue, but I do see now that there's a wasm-ld: warning: function signature mismatch message that gets printed when the problem is present.

Would it make sense for cases like this to be treated as errors rather than warnings? (Although I do have ERROR_ON_UNDEFINED_SYMBOLS enabled, which may or may not affect the behavior here.)

@kripken feel free to close this ticket unless it's still helpful to keep open.

[kripken]

@buu700 Thanks for the update. Interesting, sounds like this might be undefined behavior then, which the LLVM backend optimizes in more dangerous ways than fastcomp did.

Yes, let's close this as there isn't anything specific to fix at this time. If we can get specific reproducers for the other problems mentioned throughout this issue let's file those separately.

About wasm-ld: warning: function signature mismatch, I hope that would be an error if you link with -Werror to turn warnings to errors. @sbc100 does that flag apply to wasm-ld warnings too?

[sbc100]

Regarding wasm-ld warnings, yes you can do -Wl,--fatal-warnings.