profile
viewpoint

Ask questionsmonerod crashes during resync: Exception in threadpool

When running monerod on latest 0.17.1.1, the node repeatedly crashes during resync with the following output:

2020-10-31 15:18:25.197 [P2P3]  INFO    global  src/cryptonote_protocol/cryptonote_protocol_handler.inl:368     [70.180.135.90:18080 OUT] Sync data returned a new top block candidate: 2210000 -> 2220390 [Your node is 10390 blocks (14.4 days) behind] 
2020-10-31 15:18:25.197 [P2P3]  INFO    global  src/cryptonote_protocol/cryptonote_protocol_handler.inl:368     SYNCHRONIZATION started
2020-10-31 15:18:30.508 [P2P0]  ERROR   default src/common/threadpool.cpp:170   Exception in threadpool job: mprotect failed

I am running monerod v0.17.1.1 on Ubuntu 20.04.

monero-project/monero

Answer questions tevador

According to the systemd man pages, this is not a bug but the intended behavior of the MemoryDenyWriteExecute option:

MemoryDenyWriteExecute= Takes a boolean argument. If set, attempts to create memory mappings that are writable and executable at the same time, or to change existing memory mappings to become executable, or mapping shared memory segments as executable are prohibited. Specifically, a system call filter is added that rejects mmap(2) system calls with both PROT_EXEC and PROT_WRITE set, mprotect(2) or pkey_mprotect(2) system calls with PROT_EXEC set and shmat(2) system calls with SHM_EXEC set. Note that this option is incompatible with programs and libraries that generate program code dynamically at runtime, including JIT execution engines, executable stacks, and code "trampoline" feature of various C compilers.

Emphasis mine. The issue is that it not only enforces W^X, but also prevents existing mappings from being made executable. No JIT compiled code can work under these circumstances. If you insist about having it on, you need to use MONERO_RANDOMX_UMASK=8, which disables JIT altogether (at the cost of a much slower synchronization).

useful!
source:https://uonfu.com/
Github User Rank List