After update to dev-libs/crypto++-8.3.0, net-p2p/amule-2.3.2-r5 always crashes. Reproducible: Always Steps to Reproduce: 1. emereg =dev-libs/crypto++-8.3.0 2. run amule Actual Results: 21:35:51 ~ $ amule 2020-12-28 21:35:54: Initialising aMule 2.3.2 compiled with wxGTK2 v3.0.4 and Boost 1.74 2020-12-28 21:35:54: Checking if there is an instance already running... 2020-12-28 21:35:54: No other instances are running. -------------------------------------------------------------------------------- A fatal error has occurred and aMule has crashed. Please assist us in fixing this problem by posting the backtrace below in our 'aMule Crashes' forum and include as much information as possible regarding the circumstances of this crash. The forum is located here: http://forum.amule.org/index.php?board=67.0 If possible, please try to generate a real backtrace of this crash: http://wiki.amule.org/wiki/Backtraces ----------------------------=| BACKTRACE FOLLOWS: |=---------------------------- Current version is: aMule 2.3.2 compiled with wxGTK2 v3.0.4 and Boost 1.74 Running on: Linux 5.9.8-gentoo x86_64 [2] ?? in /usr/lib64/libwx_baseu-3.0-gtk3.so.0[0x7f99e70033b0] [3] ?? in /lib64/libpthread.so.0[0x7f99e7fab8a0] [4] ?? in /usr/lib64/libcryptopp.so.8[0x7f99e7b820ac] [5] CryptoPP::Integer::Decode(CryptoPP::BufferedTransformation&, unsigned long, CryptoPP::Integer::Signedness) in /usr/lib64/libcryptopp.so.8[0x7f99e7b84ee2] [6] CryptoPP::Integer::BERDecode(CryptoPP::BufferedTransformation&) in /usr/lib64/libcryptopp.so.8[0x7f99e7b8c7ae] [7] CryptoPP::InvertibleRSAFunction::BERDecodePrivateKey(CryptoPP::BufferedTransformation&, bool, unsigned long) in /usr/lib64/libcryptopp.so.8[0x7f99e7cdc10b] [8] CryptoPP::PKCS8PrivateKey::BERDecode(CryptoPP::BufferedTransformation&) in /usr/lib64/libcryptopp.so.8[0x7f99e7b98918] [9] ?? in amule[0x56236b9e008c] [10] ?? in amule[0x56236b9e1394] [11] ?? in amule[0x56236b9c7b94] [12] ?? in amule[0x56236ba89177] [13] wxEntry(int&, wchar_t**) in /usr/lib64/libwx_baseu-3.0-gtk3.so.0[0x7f99e6f4b462] [14] main in amule[0x56236b99d838] [15] __libc_start_main in /lib64/libc.so.6[0x7f99e68b9e3a] [16] ?? in amule[0x56236b9b04da] -------------------------------------------------------------------------------- Aborted (core dumped) amule works again after down to dev-libs/crypto++-8.2.0-r2.
Does it work if you rebuild amule after the update?
(In reply to jospezial from comment #1) > Does it work if you rebuild amule after the update? Thanks @jospezial. I think that is probably the course of action to take here. We have a test script that looks for version incompatibilities at https://github.com/weidai11/cryptopp/blob/master/TestScripts/cryptest-symbols.sh. It ensures no symbols go missing, and running Crypto++ 8.2 executables against Crypto++ 8.3 shared object are OK. We did not witness trouble testing Crypto++ 8.2 executables against Crypto++ 8.3 shared object. I'll be keeping an eye on this with you.
(In reply to jospezial from comment #1) > Does it work if you rebuild amule after the update? Works after rebuild amule, thank you :)
(In reply to Jeffrey Walton from comment #2) > (In reply to jospezial from comment #1) > > Does it work if you rebuild amule after the update? > > Thanks @jospezial. > > I think that is probably the course of action to take here. > > I'll be keeping an eye on this with you. Thanks a bunch for showing up here - I saw https://github.com/weidai11/cryptopp/issues/987 and was really impressed with your attitude there. Working with downstream like that is a huge help. (In reply to Drunkard Zhang from comment #3) > (In reply to jospezial from comment #1) > > Does it work if you rebuild amule after the update? > > Works after rebuild amule, thank you :) That's interesting. I'm reluctant to bump the subslot (ABI version in Gentoo) because upstream haven't yet found the problem...
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b35ea9fc7bf503858f0135f86afb65906cefa704 commit b35ea9fc7bf503858f0135f86afb65906cefa704 Author: Sam James <sam@gentoo.org> AuthorDate: 2020-12-29 07:26:47 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2020-12-29 07:26:52 +0000 dev-libs/crypto++: drop back to ~arch for now There's possible ABI breakage so dropping back to ~arch for more testing, pending further investigation. Bug: https://bugs.gentoo.org/762241 Package-Manager: Portage-3.0.12-prefix, Repoman-3.0.2 Signed-off-by: Sam James <sam@gentoo.org> dev-libs/crypto++/crypto++-8.3.0.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
(In reply to Jeffrey Walton from comment #2) > (In reply to jospezial from comment #1) > > Does it work if you rebuild amule after the update? > > Thanks @jospezial. > > I think that is probably the course of action to take here. > > We have a test script that looks for version incompatibilities at > https://github.com/weidai11/cryptopp/blob/master/TestScripts/cryptest- > symbols.sh. It ensures no symbols go missing, and running Crypto++ 8.2 > executables against Crypto++ 8.3 shared object are OK. Okay, I asked the ABI Laboratory guy to add 8.3.0 to his site [0] (he's very friendly!) It looks like a few symbols have gone missing but (possibly more importantly) the size of some structures has changed. This is likely what's broken amule here and other reverse dependencies. In such cases, building/linking will succeed but random runtime failure can occur. This might be why the script didn't pick it up? I'm poking a bit more with tools [1] by the same upstream author. [0] https://abi-laboratory.pro/index.php?view=compat_report&l=cryptopp&v1=8_2_0&v2=8_3_0&obj=e8fc4&kind=abi#Type_Problems_High [1] https://lvc.github.io/abi-compliance-checker/ (in tree as dev-util/abi-compliance-checker)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=98694720dc1c5c4e9d194d3c6fe01a4faac442b1 commit 98694720dc1c5c4e9d194d3c6fe01a4faac442b1 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-01-02 07:08:41 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-01-02 07:08:41 +0000 dev-libs/crypto++: bump to 8.4.0 Notes: * This increments the subslot to 8.4 because of the (unintentional) ABI breakage in 8.3. * The CVE is no longer fixed as the change had to be reverted upstream. Bug: https://bugs.gentoo.org/702930 Closes: https://bugs.gentoo.org/762241 Package-Manager: Portage-3.0.12, Repoman-3.0.2 Signed-off-by: Sam James <sam@gentoo.org> dev-libs/crypto++/Manifest | 2 +- dev-libs/crypto++/{crypto++-8.3.0.ebuild => crypto++-8.4.0.ebuild} | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a0855564a0721d066a598a7d2e420a98a525e49d commit a0855564a0721d066a598a7d2e420a98a525e49d Author: Sam James <sam@gentoo.org> AuthorDate: 2021-01-02 07:12:13 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-01-02 07:12:13 +0000 app-crypt/codecrypt: revbump for dev-libs/crypto++ subslot dep Bug: https://bugs.gentoo.org/762241 Package-Manager: Portage-3.0.12, Repoman-3.0.2 Signed-off-by: Sam James <sam@gentoo.org> .../codecrypt/{codecrypt-1.7.2.ebuild => codecrypt-1.7.2-r1.ebuild} | 4 ++-- .../codecrypt/{codecrypt-1.8-r1.ebuild => codecrypt-1.8-r2.ebuild} | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=415585e83f58ec3d8b831ae4c63b8490d6259615 commit 415585e83f58ec3d8b831ae4c63b8490d6259615 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-01-02 07:09:08 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-01-02 07:09:08 +0000 profiles/package.mask: drop obsolete =dev-libs/crypto++-8.3.0 mask Bug: https://bugs.gentoo.org/762241 Signed-off-by: Sam James <sam@gentoo.org> profiles/package.mask | 7 ------- 1 file changed, 7 deletions(-)
