[bug] 1.14.6 runtime error with intel-avx2 option

[victorsk2019]

Hello!
Current behavior:
When launching either dogecoin-qt or dogecoind I get the following error:

dogecoin-qt: chainparams.cpp:160: CMainParams::CMainParams(): Assertion consensus.hashGenesisBlock == uint256S("0x1a91e3dace36e2be3bf030a65679fe821aa1d6ef92e7c9902eb318182c355691")' failed. Aborted

I discovered this issue after installing Dogecoin Core 1.14.6 from Gentoo's Guru overlay which automatically detects and sets intel-avx2 option if avx2 CPU extension is available. So I kept getting above noted error on my Dell system with avx2 support on BTRFS filesystem that I set up Gentoo-based system on.

Expected behavior
The application should start and run normally without this error with intel-avx2 selection.

Steps to reproduce:
This issue can likely be reproduced on BTRFS installation with CPU supporting avx2 extension and using with-intel-avx2 configure option.

Dogecoin Core version
1.14.6

Machine specs

• OS: Calculate Linux (Gentoo-based)
• CPU: Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz
• RAM: 6GB
• Disk size: 450GB
• Disk Type (HD/SDD): HD

Please note, the issue gets fixed if building Dogecoin Core without intel-avx2 option on my system so, naturally, this option is the most likely cause of the problem.

Thanks!

[patricklodder]

Could you please share your config.log?

[edtubbs]

For avx2 support, you have to build core with depends as there's a patch for intel-ipsec-mb. We're investigating the possibility of removing the patch for 1.14.7. You can find more information about depends at: https://github.com/dogecoin/dogecoin/tree/master/depends

[victorsk2019]

Thank you @edtubbs for information. Per @patricklodder request, I'm attaching my config.log

I am also examining these logs and will check on the use of depends, as advised.

P.S. My Mac recently went kaput so I won't be able to address Mac-related issues in #3260 for a while. So I dug up my old Dell laptop instead 😎

[patricklodder]

For avx2 support, you have to build core with depends as there's a patch for intel-ipsec-mb

Based on what I see in config.log, this is likely the cause. It would be good to test for that patch with ./configure.

P.S. My Mac recently went kaput so I won't be able to address Mac-related issues in #3260 for a while.

There's still review pending on #3308 - once that is done I'll propose something for the CI part of #3260 including that patch

[victorsk2019]

Hi,

Thank you again for prompt responses. The issue is fixed when applying suggested patch, which I was able to re-create for Gentoo system like so:

diff --git a/lib/include/sha_generic.h b/lib/include/sha_generic.h
index 9329da2..26d6d4e 100644
--- a/lib/include/sha_generic.h
+++ b/lib/include/sha_generic.h
@@ -323,7 +323,7 @@ void sha_generic_1block(const void *data, void *digest,
                 return;
         }
 #endif
-        sha_generic_init(digest, sha_type);
+        // sha_generic_init(digest, sha_type);
         sha_generic_one_block(data, digest, is_avx, sha_type);
 #ifdef SAFE_DATA
         clear_scratch_gps();

which, as I understand it, boils down to commenting out sha_generic_init() function.

I applied this patch to app-crypt/intel-ipsec-mb and was able to successfully launch and run Dogecoin Core with avx2 enabled.

Since intel-ipsec-mb is conveniently provided in Gentoo's Guru package overlay, I have to find a way to automatically patch app-crypt/intel-ipsec-mb from my own ebuild and I am not yet sure if it's possible, so I am not out of the woods with this issue just yet. However, since in a general sense a patch to this problem is available, I guess it may not be considered a bug in this sense then?

[patricklodder]

However, since in a general sense a patch to this problem is available, I guess it may not be considered a bug in this sense then?

To me, the "bug" is simply a missing check during configuration, where we make sure that when someone custom compiles against a non-patched intel-ipsec-mb, we error out at that time, and not at runtime.

[victorsk2019]

To me, the "bug" is simply a missing check during configuration, where we make sure that when someone custom compiles against a non-patched intel-ipsec-mb, we error out at that time, and not at runtime.

Hi,

I have recently implemented this process gentoo/guru@5e67e95

Thank you,
Victor.