macOS v0.19.1 failing test: memory access violation at address: 0x02800000: no mapping at fault address #18776

ISSUE: I'm noticing that 0.19.1 fails a particular test:

wallet/test/psbt_wallet_tests.cpp:17: Entering test case "psbt_updater_test"

unknown location:0: fatal error: in "psbt_wallet_tests/psbt_updater_test": memory access violation at address: 0x02800000: no mapping at fault address

wallet/test/psbt_wallet_tests.cpp:17: last checkpoint: "psbt_updater_test" fixture ctor Test is aborted

What behavior did you expect?

make passes all the tests

What was the actual behavior (provide screenshots if the issue is GUI-related)?

<img width="565" alt="image" src="https://user-images.githubusercontent.com/24903257/80319804-8dd21180-87e0-11ea-8b13-3c21c8b0a7a5.png">

How reliably can you reproduce the issue, what are the steps to do so?

$ make check

Easily reproducible

What version of Bitcoin Core are you using, where did you get it (website, self-compiled, etc)?

Bitcoin Core v0.19.1 I cloned the repo from the official Bitcoin project and then built it from source.

What type of machine are you observing the error on (OS/CPU and disk type)?

macOS Catalina 10.15.4

GUI-related issue? What is your operating system and its version? If Linux, what is your desktop environment and graphical shell?

No

Any extra information that might be useful in the debugging process. --> This is normally the contents of a debug.log or config.log file. Raw text or a link to a pastebin type site are preferred.

$ grep PACKAGE_STRING= ./config.log PACKAGE_STRING='Bitcoin Core 0.19.1'

$ head -n 20 ./src/fs.h or git log -1 ==> ./src/fs.h <== // Copyright (c) 2017-2018 The Bitcoin Core developers // Distributed under the MIT software license, see the accompanying // file COPYING or http://www.opensource.org/licenses/mit-license.php.

#ifndef BITCOIN_FS_H #define BITCOIN_FS_H

#include <stdio.h> #include #if defined WIN32 && defined GLIBCXX #include <ext/stdio_filebuf.h> #endif

#include <boost/filesystem.hpp> #include <boost/filesystem/fstream.hpp>

/** Filesystem operations and types */ namespace fs = boost::filesystem;

/** Bridge operations to C stdio */ head: or: No such file or directory head: git: No such file or directory head: log: No such file or directory head: -1: No such file or directory

Same on armhf: #15062

I'd like to work on this issue and I think the first thing I should start is to examine and understand the corresponding test. Is this a good first step to solving this issue?

Can you run in valgrind?

valgrind ./src/test/test_bitcoin

Sure! Let me build Valgrind and then run the command.

This is the output:

==90288== Memcheck, a memory error detector ==90288== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==90288== Using Valgrind-3.16.0.GIT and LibVEX; rerun with -h for copyright info ==90288== Command: ./src/test/test_bitcoin ==90288== --90288-- run: /usr/bin/dsymutil "./src/test/test_bitcoin" --90288-- UNKNOWN fcntl 101! --90288-- UNKNOWN fcntl 101! (repeated 2 times) --90288-- UNKNOWN fcntl 101! (repeated 4 times) --90288-- UNKNOWN fcntl 101! (repeated 8 times) --90288-- UNKNOWN fcntl 101! (repeated 16 times) --90288-- UNKNOWN fcntl 101! (repeated 32 times) ==90288== valgrind: Unrecognised instruction at address 0x101c55a73. ==90288== at 0x101C55A73: __pthread_init.cold.2 (in /usr/lib/system/libsystem_pthread.dylib) ==90288== by 0x10111D72D: libSystem_initializer (in /usr/lib/libSystem.B.dylib) ==90288== by 0x100FCF1E2: ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in /usr/lib/dyld) ==90288== by 0x100FCF5ED: ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) (in /usr/lib/dyld) ==90288== by 0x100FCA00A: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld) ==90288== by 0x100FC9F75: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld) ==90288== by 0x100FC8013: ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld) ==90288== by 0x100FC80B3: ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld) ==90288== by 0x100FB659F: dyld::initializeMainExecutable() (in /usr/lib/dyld) ==90288== by 0x100FBBAF7: dyld::_main(macho_header const, unsigned long, int, char const, char const, char const**, unsigned long) (in /usr/lib/dyld) ==90288== by 0x100FB5226: dyldbootstrap::start(dyld3::MachOLoaded const, int, char const**, dyld3::MachOLoaded const, unsigned long) (in /usr/lib/dyld) ==90288== by 0x100FB5024: _dyld_start (in /usr/lib/dyld) ==90288== Your program just tried to execute an instruction that Valgrind ==90288== did not recognise. There are two possible reasons for this. ==90288== 1. Your program has a bug and erroneously jumped to a non-code ==90288== location. If you are running Memcheck and you just saw a ==90288== warning about a bad jump, it's probably your program's fault. ==90288== 2. The instruction is legitimate but Valgrind doesn't handle it, ==90288== i.e. it's Valgrind's fault. If you think this is the case or ==90288== you are not sure, please let us know and we'll try to fix it. ==90288== Either way, Valgrind will now raise a SIGILL signal which will ==90288== probably kill your program. ==90288== ==90288== Process terminating with default action of signal 4 (SIGILL) ==90288== Illegal opcode at address 0x101C55A73 ==90288== at 0x101C55A73: __pthread_init.cold.2 (in /usr/lib/system/libsystem_pthread.dylib) ==90288== by 0x10111D72D: libSystem_initializer (in /usr/lib/libSystem.B.dylib) ==90288== by 0x100FCF1E2: ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in /usr/lib/dyld) ==90288== by 0x100FCF5ED: ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) (in /usr/lib/dyld) ==90288== by 0x100FCA00A: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld) ==90288== by 0x100FC9F75: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld) ==90288== by 0x100FC8013: ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld) ==90288== by 0x100FC80B3: ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld) ==90288== by 0x100FB659F: dyld::initializeMainExecutable() (in /usr/lib/dyld) ==90288== by 0x100FBBAF7: dyld::_main(macho_header const, unsigned long, int, char const, char const, char const, unsigned long) (in /usr/lib/dyld) ==90288== by 0x100FB5226: dyldbootstrap::start(dyld3::MachOLoaded const, int, char const, dyld3::MachOLoaded const, unsigned long) (in /usr/lib/dyld) ==90288== by 0x100FB5024: _dyld_start (in /usr/lib/dyld) ==90288== ==90288== HEAP SUMMARY: ==90288== in use at exit: 0 bytes in 0 blocks ==90288== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==90288== ==90288== All heap blocks were freed -- no leaks are possible ==90288== ==90288== For lists of detected and suppressed errors, rerun with: -s ==90288== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1) Illegal instruction: 4

That doesn't look helpful. Maybe try gdb?

I'm just setting breakpoints and then stepping through the test in order to look for the error, correct? Is there a more efficient/recommended debugging strategy?

Ok, found the test case in question. Will be setting breakpoints here and stepping through it:

https://github.com/bitcoin/bitcoin/blob/master/src/wallet/test/psbt_wallet_tests.cpp

Having trouble running the tests now using make:

<img width="573" alt="image" src="https://user-images.githubusercontent.com/24903257/80394094-61b99d80-887f-11ea-8d72-313470442483.png">

Similar to this issue: #17664 , but it's not 100% clear what the resolution was. Besides reinstalling my repo, is there a solution to this?

make distclean will clear your repo of compiled files and the configure result

Great, that worked, thanks!

Do you think it would be a good idea to detail using make distclean in the build directions here: https://github.com/bitcoin/bitcoin/blob/master/doc/build-osx.md

Do you happen to use lldb: https://gist.github.com/fjahr/2cd23ad743a2ddfd4eed957274beca0f#gistcomment-3272312

I don't use lldb. What happens if you don't set any breakpoint and just run?

Running...

<img width="569" alt="image" src="https://user-images.githubusercontent.com/24903257/80426029-e07bfe00-88b2-11ea-8c1a-50154d76f401.png">

And then do thread apply all bt

<img width="569" alt="image" src="https://user-images.githubusercontent.com/24903257/80426203-423c6800-88b3-11ea-8f0a-dee3e69f0bbe.png">

Looks like an upstream issue with bdb

Would this affect my ability to debug using gdb?

Not sure there's anything to follow up with here at the moment. If someone can recreate the issue with master we could revisit.