From: "Eregon (Benoit Daloze)" <noreply@ruby-lang.org>
To: ruby-core@ruby-lang.org
Subject: [ruby-core:107207] [Ruby master Bug#18249] The ABI version of dev builds of CRuby does not correspond to the ABI
Date: Thu, 20 Jan 2022 18:08:17 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-96069.20220120180816.772@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-18249.20211011175849.772@ruby-lang.org
Issue #18249 has been updated by Eregon (Benoit Daloze).
@peterzhu2118 That's great, thank you for this work!
> In Ruby, the ABI version is exposed through RbConfig::CONFIG["rb_abi_version"].
I would have a preference for `RbConfig::CONFIG["abi_version"]`, the `rb_` prefix seems redundant there.
----------------------------------------
Bug #18249: The ABI version of dev builds of CRuby does not correspond to the ABI
https://bugs.ruby-lang.org/issues/18249#change-96069
* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
In fact, it even conflicts with the next release's ABI version:
```
$ ruby -ve 'p RbConfig::CONFIG["ruby_version"]'
ruby 3.1.0dev (2021-10-11T10:13:16Z master 0c3ac87345) [x86_64-linux]
"3.1.0"
```
This mismatch can very easily result in segfaults, memory corruption, etc when using dev versions of CRuby,
or when using a dev version and then later the release.
Possible solutions:
* Include the git commit sha in the ABI. Pros: always correct and simple. Cons: changing more then necessary.
* Track the ABI explicitly, and bump it whenever the ABI changes. Pros: changes only when needed. Cons: easy to forget bumping it, and if checked in CI already too late.
From https://bugs.ruby-lang.org/issues/18239#note-14:
FWIW TruffleRuby actually tracks the ABI of dev versions through [this file](https://github.com/oracle/truffleruby/blob/master/lib/cext/ABI_version.txt) which means it is possible to sensibly cache compiled gems even for dev versions [details](https://github.com/oracle/truffleruby/issues/2284).
Also it [stores](https://github.com/oracle/truffleruby/commit/d497bae73fdc60585b66cd183768a16563b2886b) the ABI version in .so/.bundle files and checks them when loading, so it can be sure the ABI used to compile and runtime ABI match (if not, an exception is raised).
ruby/setup-ruby has no choice for CRuby dev but [to use the commit](https://github.com/ruby/setup-ruby/blob/a6f22865941e122a37e097fbded3dd0b54c39207/bundler.js#L188) as the ABI version.
This issue is made worse by Ruby switchers like RVM & chruby setting GEM_HOME (so the ABI is effectively ignored by RubyGems in those cases, and those directories need to be cleaned manually).
When GEM_HOME is not set, it would be enough to rebuild CRuby dev and remove the directory before installing (which includes both CRuby & gems), but Ruby installers don't do that yet.
Bundler always includes the ABI version when setting the bundler path (`bundle config --local path`), but if the ABI version is incorrect like for CRuby dev it's of no use.
--
https://bugs.ruby-lang.org/
next prev parent reply other threads:[~2022-01-20 18:08 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-11 17:58 [ruby-core:105618] [Ruby master Bug#18249] The ABI version of dev builds of CRuby does not correspond to the ABI Eregon (Benoit Daloze)
2022-01-20 16:48 ` [ruby-core:107206] " peterzhu2118 (Peter Zhu)
2022-01-20 18:08 ` Eregon (Benoit Daloze) [this message]
2022-01-20 18:46 ` [ruby-core:107208] " Eregon (Benoit Daloze)
2022-01-20 19:28 ` [ruby-core:107209] " peterzhu2118 (Peter Zhu)
2022-01-20 21:48 ` [ruby-core:107210] " byroot (Jean Boussier)
2022-01-21 6:39 ` [ruby-core:107221] " nobu (Nobuyoshi Nakada)
2022-01-21 8:02 ` [ruby-core:107222] " naruse (Yui NARUSE)
2022-01-21 9:28 ` [ruby-core:107225] " nobu (Nobuyoshi Nakada)
2022-01-21 14:16 ` [ruby-core:107228] " peterzhu2118 (Peter Zhu)
2022-01-21 14:48 ` [ruby-core:107229] " Eregon (Benoit Daloze)
2022-01-21 14:53 ` [ruby-core:107230] " Eregon (Benoit Daloze)
2022-01-21 17:08 ` [ruby-core:107232] " peterzhu2118 (Peter Zhu)
2022-02-01 20:37 ` [ruby-core:107420] " peterzhu2118 (Peter Zhu)
2022-02-17 5:59 ` [ruby-core:107611] " matz (Yukihiro Matsumoto)
2022-02-17 9:06 ` [ruby-core:107618] " hsbt (Hiroshi SHIBATA)
2022-02-17 12:51 ` [ruby-core:107630] " Eregon (Benoit Daloze)
2022-02-17 14:13 ` [ruby-core:107638] " peterzhu2118 (Peter Zhu)
2022-02-17 16:20 ` [ruby-core:107641] " Dan0042 (Daniel DeLorme)
2022-02-17 16:39 ` [ruby-core:107642] " peterzhu2118 (Peter Zhu)
2022-02-17 17:44 ` [ruby-core:107645] " Eregon (Benoit Daloze)
2022-02-17 17:45 ` [ruby-core:107646] " Eregon (Benoit Daloze)
2022-02-18 4:41 ` [ruby-core:107653] " hsbt (Hiroshi SHIBATA)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.journal-96069.20220120180816.772@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).