Segmentaton fault on cnv8, compiled with gcc7

[srwx666]

Please provide as much as possible information to reproduce the issue.

lastest dev branch compiled with gcc7

running config with cnv7 mines ok running the same config withh only changed to cnv8 segmentation fault

strace.txt

compiled with gccv6 no problems at all

Basic information

• Type of the CPU.

CPU E5-2699 v4

Compile issues

• Which OS do you use?

CentOS Linux release 7.3.1611 (Core)

cmake3 .. -DCUDA_ENABLE=OFF -DOpenCL_ENABLE=OFF -DCMAKE_LINK_STATIC=ON -DHWLOC_ENABLE=OFF

-- The C compiler identification is GNU 7.1.1
-- The CXX compiler identification is GNU 7.1.1
-- Check for working C compiler: /opt/rh/devtoolset-7/root/usr/bin/cc
-- Check for working C compiler: /opt/rh/devtoolset-7/root/usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /opt/rh/devtoolset-7/root/usr/bin/c++
-- Check for working CXX compiler: /opt/rh/devtoolset-7/root/usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Found OpenSSL: /usr/lib64/libssl.so;/usr/lib64/libcrypto.so (found version "1.0.2k")
-- The ASM compiler identification is GNU
-- Found assembler: /opt/rh/devtoolset-7/root/usr/bin/cc
-- Configuring done
-- Generating done
-- Build files have been written to: /root/xmr-stak2.4-v8/build

CMAKE_AR:FILEPATH=/opt/rh/devtoolset-7/root/usr/bin/ar CMAKE_ASM_COMPILER:FILEPATH=/opt/rh/devtoolset-7/root/usr/bin/cc CMAKE_ASM_FLAGS:STRING= CMAKE_ASM_FLAGS_DEBUG:STRING=-g CMAKE_ASM_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG CMAKE_ASM_FLAGS_RELEASE:STRING=-O2 -DNDEBUG CMAKE_ASM_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG CMAKE_BUILD_TYPE:STRING=Release CMAKE_COLOR_MAKEFILE:BOOL=ON CMAKE_CXX_COMPILER:FILEPATH=/opt/rh/devtoolset-7/root/usr/bin/c++ CMAKE_CXX_FLAGS:STRING= CMAKE_CXX_FLAGS_DEBUG:STRING=-g CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG CMAKE_CXX_FLAGS_RELEASE:STRING=-O2 -DNDEBUG CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG CMAKE_C_COMPILER:FILEPATH=/opt/rh/devtoolset-7/root/usr/bin/cc CMAKE_C_FLAGS:STRING= CMAKE_C_FLAGS_DEBUG:STRING=-g CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG CMAKE_C_FLAGS_RELEASE:STRING=-O2 -DNDEBUG CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG CMAKE_EXE_LINKER_FLAGS:STRING= CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING= CMAKE_EXE_LINKER_FLAGS_MINSIZEREL:STRING= CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING= CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING= CMAKE_EXPORT_COMPILE_COMMANDS:BOOL=OFF CMAKE_INSTALL_PREFIX:PATH=/root/suzumushi/miners/xmr-stak2.4-v8/build CMAKE_LINKER:FILEPATH=/opt/rh/devtoolset-7/root/usr/bin/ld CMAKE_LINK_STATIC:BOOL=ON CMAKE_MAKE_PROGRAM:FILEPATH=/opt/rh/devtoolset-7/root/usr/bin/gmake CMAKE_MODULE_LINKER_FLAGS:STRING= CMAKE_MODULE_LINKER_FLAGS_DEBUG:STRING= CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL:STRING= CMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING= CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO:STRING= CMAKE_NM:FILEPATH=/opt/rh/devtoolset-7/root/usr/bin/nm CMAKE_OBJCOPY:FILEPATH=/opt/rh/devtoolset-7/root/usr/bin/objcopy CMAKE_OBJDUMP:FILEPATH=/opt/rh/devtoolset-7/root/usr/bin/objdump CMAKE_RANLIB:FILEPATH=/opt/rh/devtoolset-7/root/usr/bin/ranlib CMAKE_SHARED_LINKER_FLAGS:STRING= CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING= CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL:STRING= CMAKE_SHARED_LINKER_FLAGS_RELEASE:STRING= CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO:STRING= CMAKE_SKIP_INSTALL_RPATH:BOOL=NO CMAKE_SKIP_RPATH:BOOL=NO CMAKE_STATIC_LINKER_FLAGS:STRING= CMAKE_STATIC_LINKER_FLAGS_DEBUG:STRING= CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL:STRING= CMAKE_STATIC_LINKER_FLAGS_RELEASE:STRING= CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO:STRING= CMAKE_STRIP:FILEPATH=/opt/rh/devtoolset-7/root/usr/bin/strip CMAKE_VERBOSE_MAKEFILE:BOOL=FALSE CPU_ENABLE:BOOL=ON CUDA_ENABLE:BOOL=OFF EXECUTABLE_OUTPUT_PATH:STRING=bin HWLOC_ENABLE:BOOL=OFF LIBRARY_OUTPUT_PATH:STRING=bin MHTD:FILEPATH=/usr/lib64/libmicrohttpd.so MICROHTTPD_ENABLE:BOOL=ON MTHD_INCLUDE_DIR:PATH=/usr/include OPENSSL_CRYPTO_LIBRARY:FILEPATH=/usr/lib64/libcrypto.so OPENSSL_INCLUDE_DIR:PATH=/usr/include OPENSSL_SSL_LIBRARY:FILEPATH=/usr/lib64/libssl.so OpenCL_ENABLE:BOOL=OFF OpenSSL_ENABLE:BOOL=ON PKG_CONFIG_EXECUTABLE:FILEPATH=/usr/bin/pkg-config XMR-STAK_COMPILE:STRING=native

# Issue with the execution
  - Do you compiled the miner by our own?
yes

run ./xmr-stak --version-long and add the output here

Version: xmr-stak/2.4.7/a6ecf8d/dev/lin/cpu/20

# Stability issue
  - Is the CPU or GPU overclocked?
no
  - Is the Main memory of the CPU or GPU undervolted?
no

[Spudz76]

I believe this is due to RedHat being hardened more than normal distros The same thing happens if you run on Ubuntu unhardened but under systemd with MemoryDenyWriteExecute=true which adds a specific hardening measure.

SIGSEGV alludes to RedHat being unfriendly to executing the ASM code from a "data" section of memory. Need to locate the memory and mark the zone permissions properly or hardened Linux will be pedantic about it.

[Spudz76]

OK, go to where your xmr-stak binary is and try: readelf xmr-stak -l | grep -A1 STACK | grep -B1 RWE Any output proves it requires executable stack.

RedHat blocks this in their kernels because security is more important than getting anything done.

Either turn it off completely since it's annoying and arguably blocks nothing: cat /proc/sys/kernel/exec-shield (should say 2 by default, on unless all has goofbits set to disable) echo 1 > /proc/sys/kernel/exec-shield (off unless app has goofbits set to enable) echo 0 > /proc/sys/kernel/exec-shield (act like normal unparanoid Linux don't bother with shielding)

...or, set the goofbits on the executable so it stops caring about it specifically. execstack -q xmr-stak (should show - status) execstack -s xmr-stak execstack -q xmr-stak (should show 'X' status)

However some have reported the goofbits method not working and end up just shutting the dumb hack off.

[Spudz76]

Please apply this to dev and see if it all works correctly then. Should stop the exec-stack problem AND get rid of some other problems gcc7 might have had with the code.

redhat-testfix.patch.txt

[psychocrypt]

@srwx666 I think to solve the issue it is also enough to remove the file config.txt or set the option for slow mem to "use_slow_memory" : "warn". Never the less could you please post your current config.txt before you remove the old file.

[Spudz76]

@psychocrypt it's not the memory allocation it's the executing things from stack (the new ASM module ends up there unless you tell GCC no to, apparently) Which didn't occur until the ASM modules got linked (no-asm versions never made execstack even by accident)

Patch above also fixes the Systemd issue, works with protected memory with the same -Wl,-z,noexecstack fixup

The rest of the patch only gets rid of misleading alloc warnings and falls back instead when HUGETLB doesn't work (and I have not seen any speed difference either way). Some kernels don't let you hugepage (hypervisors, RedHat...) very easily or it breaks other things the system is running if mining is not its primary job. Also fixes the malloc calls since every doc I found said you call it with NULL (not 0) first argument and fd -1 (not 0) which I came across while trying to find out why this strace shows mmap(0, which will never work. I figure gcc7 doesn't do sizeof(struct) on that context object anymore (so I made the sizeof a static number define).

If this patch gets compiled and checked on this system it will prove my opinions.

[srwx666]

OK, go to where your xmr-stak binary is and try: readelf xmr-stak -l | grep -A1 STACK | grep -B1 RWE Any output proves it requires executable stack.

yes, that's correct, rhel7 and centos7 requires

RedHat blocks this in their kernels because security is more important than getting anything done.

Either turn it off completely since it's annoying and arguably blocks nothing: cat /proc/sys/kernel/exec-shield (should say 2 by default, on unless all has goofbits set to disable) echo 1 > /proc/sys/kernel/exec-shield (off unless app has goofbits set to enable) echo 0 > /proc/sys/kernel/exec-shield (act like normal unparanoid Linux don't bother with shielding)

this is not possible anymore.... as there is no option in /proc and according to rh/centos documentation

"Exec-shield is no longer an option in sysctl for kernel tuning. This is a security measure"

...or, set the goofbits on the executable so it stops caring about it specifically. execstack -q xmr-stak (should show - status) execstack -s xmr-stak execstack -q xmr-stak (should show 'X' status)

[root@localhost bin]# execstack -q xmr-stak247-gcc7 X xmr-stak247-gcc7

but unfortunatley still segfaults.

However some have reported the goofbits method not working and end up just shutting the dumb hack off.

[srwx666]

Please apply this to dev and see if it all works correctly then. Should stop the exec-stack problem AND get rid of some other problems gcc7 might have had with the code.

redhat-testfix.patch.txt

[root]# patch -p1 < redhat-testfix.patch.txt patching file CMakeLists.txt patching file xmrstak/backend/cpu/crypto/cryptonight.h patching file xmrstak/backend/cpu/crypto/cryptonight_common.cpp

[root@localhost bin]# readelf xmr-stak247-gcc7 -l | grep -A1 STACK | grep -B1 RWE GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 10 [root@localhost bin]# execstack -q xmr-stak247-gcc7 X xmr-stak247-gcc7 [root@localhost bin]# ./xmr-stak247-gcc7

[2018-10-07 21:08:15] : Cryptonight hash self-test failed. This might be caused by bad compiler optimizations.

so basically

• set(CMAKE_CXX_FLAGS "-Wl,-z,noexecstack ${CMAKE_CXX_FLAGS}")
• set(CMAKE_C_FLAGS "-Wl,-z,noexecstack ${CMAKE_C_FLAGS}") did the trick, but there is still some problem @psychocrypt already found root cause of that... in other thread.

[psychocrypt]

could you please post your config.txt. The problem is that you can not create huge page memory. This has nothing todo with the asm.

[srwx666]

could you please post your config.txt. The problem is that you can not create huge page memory. This has nothing todo with the asm.

"currency" : "cryptonight_v8", "call_timeout" : 10, "retry_time" : 30, "giveup_limit" : 0, "verbose_level" : 3, "print_motd" : true, "h_print_time" : 60, "aes_override" : null, "use_slow_memory" : "warn", "tls_secure_algo" : true, "daemon_mode" : false, "flush_stdout" : false, "output_file" : "", "prefer_ipv4" : true, "pool_list" : [ {"pool_address" : "1.1.1.1:7777", "wallet_address" : "xxx", "rig_id" : "173", "pool_password" : "x", "use_nicehash" : true, "use_tls" : false, "tls_fingerprint" : "", "pool_weight" : 5 }, ],

[srwx666]

https://github.com/fireice-uk/xmr-stak/issues/1851#issuecomment-427550830

i was referencing to this statement, it seems like @Spudz76 redhat partch resolved coredump and malloc allocation error

but "Cryptonight hash self-test failed. This might be caused by bad compiler optimizations." is now an issue

[psychocrypt]

@srwx666 could you please download https://github.com/psychocrypt/xmr-stak/archive/topic-betterCompatibilityMemAlloc.zip and try if this is solving your issue. This is mostly the patch of @Spudz76 but with more error messages and more error handling.

[srwx666]

strace.txt Results v8

[root@localhost testsv8]# ./xmr-stak-topic-betterCompatibilityMemAlloc [2018-10-08 15:08:15] : Cryptonight hash self-test failed. This might be caused by bad compiler optimizations. [2018-10-08 15:08:15] : Self test not passed!

results v7 [root@localhost testsv8]# ./xmr-stak-topic-betterCompatibilityMemAlloc [2018-10-08 15:16:06] : Cryptonight hash self-test failed. This might be caused by bad compiler optimizations. [2018-10-08 15:16:06] : Cryptonight hash self-test failed. This might be caused by bad compiler optimizations. [2018-10-08 15:16:06] : Self test not passed!

[root@localhost testsv8]# cat /proc/meminfo | grep -i huge HugePages_Total: 1000 HugePages_Free: 1000 Hugepagesize: 2048 kB

and strace

[psychocrypt]

mhh strange. I compiled the miner also o with gcc7 and all works. could you please post the full output (really all lines)

[srwx666]

running without anu config except for cpu.txt

[root@localhost testsv8]# ./xmr-stak-topic-betterCompatibilityMemAlloc Please enter:

• Please enter the currency that you want to mine:
  • aeon7
  • bbscoin
  • bittube
  • cryptonight
  • cryptonight_bittube2
  • cryptonight_masari
  • cryptonight_haven
  • cryptonight_heavy
  • cryptonight_lite
  • cryptonight_lite_v7
  • cryptonight_lite_v7_xor
  • cryptonight_v7
  • cryptonight_v8
  • cryptonight_v7_stellite
  • graft
  • haven
  • intense
  • masari
  • monero
  • qrl
  • ryo
  • stellite
  • turtlecoin

cryptonight_v8

• Pool address: e.g. pool.example.com:3333 pool.example.com:3333
• Username (wallet address or pool login): x
• Password (mostly empty or x): x
• Rig identifier for pool-side statistics (needs pool support). Can be empty: asdasd
• Does this pool port support TLS/SSL? Use no if unknown. (y/N) n
• Do you want to use nicehash on this pool? (y/n) y
• Do you want to use multiple pools? (y/n) n Pool configuration stored in file 'pools.txt' [2018-10-08 16:25:20] : Cryptonight hash self-test failed. This might be caused by bad compiler optimizations. [2018-10-08 16:25:20] : Self test not passed! [root@localhost testsv8]#

[psychocrypt]

do you set some compiler options in your environment?

[srwx666]

scl enable devtoolset-7 bash cmake3 .. -DCUDA_ENABLE=OFF -DOpenCL_ENABLE=OFF -DCMAKE_LINK_STATIC=ON -DHWLOC_ENABLE=OFF make

and that's it

[srwx666]

Update:

problem solved by updating gcc to v 7.3

as in most cases problem between keyboard and armchair

sorry for wasting your time.

[Spudz76]

Haha, actually never considered checking which subversion of gcc7 Mine was 7.3.0 the whole time.

[psychocrypt]

solved: by gcc update to 7.3