Commit 095a8128 and non-zero exit code 139 (segfault?)

[sogaiu]

For background, please see comments starting here.

Not sure how to describe what the issue is very well ATM, but basically it appears that native bits (e.g. those made via jpm's declare-native) created prior to janet @ 095a812 don't seem to work well with janet @ 095a812 or later.

Reproduction steps are:

• Build spork (@ 4aa1d495) using janet @ 82416e4 (this is a commit before 095a812). I used jpm build to do this.
• Now using janet @ 095a812 run spork's tests. I used jpm test to do this.
• Observe error output.

Output of jpm test up to the error is below:

$ jpm test
running test/suite-argparse.janet ...
test suite test/suite-argparse.janet finished in 0.001 seconds - 17 of 17 tests passed.
running test/suite-base64.janet ...
test suite test/suite-base64.janet finished in 0.000 seconds - 22 of 22 tests passed.
running test/suite-cc.janet ...
test suite test/suite-cc.janet finished in 0.001 seconds - 12 of 12 tests passed.
running test/suite-crc.janet ...
test suite test/suite-crc.janet finished in 0.000 seconds - 7 of 7 tests passed.
non-zero exit code in test/suite-crc.janet: 139

@pyrmont mentioned something along the lines of may be this could result in problems if folks have native things installed using older versions of janet and then they go to use those bits with a new enough version of janet.

(If I got that wrong, may be he can correct / elaborate :) )

[pyrmont]

Put as succinctly as I can:

• @sogaiu seems to have discovered that if you built a native module with a previous versions of Janet, the changes made in 095a812 will cause a segfault when the Janet interpreter exits. Presumably this is because the changes to the deinitialisation logic are incompatible with the way the previous native code was generated.

• I don't think this is a theoretical problem. Users who install packages that include native modules will have code that was built with an earlier version of Janet.

• Many of those users will have a version of Janet installed by a package manager that will update automatically after v1.39.2 is released. After v1.39.2 is released, these users could find that code that was working fine will suddenly start segfaulting. Sure, it only segfaults on exit but this still seems bad.

• I'm not sure how to solve this problem. Given that this commit was aimed at addressing a real bug, I don't think it makes sense to roll it back. Perhaps the only real solution is to put an announcement in the release notes informing users that they need to reinstall any packages that use native modules but that doesn't seem great.

[sogaiu]

An additional point of concern might be when trying to test things across the "version boundary".

If native modules need to be recompiled this will increase the burden of investigation when crossing the boundary. Alternatively, separate sets of modules compiled for either side of the boundary may be prepared and upon each "crossing" the used set of modules can be switched between.

[bakpakin]

This should already be addressed by patching the minor version - when loading natives, Janet checks that the version number matches to avoid this issue - loading the latest master that had the ABI change but no minor version bump is what caused the issue

[sogaiu]

Oh nice. Thanks for the explanation!