I did not notice this until now due to user reporting issue because I created wallet and synced with hushd from terminal initially. On a completely fresh install, SD opens up this popup and then crashes when clicking OK. Trying to open again crashes again with same Performing wallet upgrade to 60000 in debug.log. If you start hushd manually and then open SD, it works fine. Not sure if there is some Mac specific code causing this issue or possibly an issue with the .dmg and packaged bins, but needs further testing.
debug.log
2022-11-06 21:24:59 Hush version v3.9.2-f4927fa54-dirty
2022-11-06 21:24:59 Using WolfSSL version 4.6.0
2022-11-06 21:24:59 Using BerkeleyDB version Berkeley DB 6.2.23: (March 28, 2016)
2022-11-06 21:24:59 Default data directory /Users/fekt/Library/Application Support/Hush/HUSH3
2022-11-06 21:24:59 Using data directory /Users/fekt/Library/Application Support/Hush/HUSH3
2022-11-06 21:24:59 Using config file /Users/fekt/Library/Application Support/Hush/HUSH3/HUSH3.conf
2022-11-06 21:24:59 Using at most 384 connections (2560 file descriptors available)
2022-11-06 21:24:59 Using 2 threads for script verification
2022-11-06 21:24:59 scheduler thread start
2022-11-06 21:24:59 Looking for sapling params, PWD=/
2022-11-06 21:24:59 Found sapling params in /Applications/Contents/MacOS
2022-11-06 21:24:59 Found sapling param in 0.000229s seconds.
2022-11-06 21:24:59 Loading Sapling (Spend) parameters from /Applications/silentdragon.app/Contents/MacOS/sapling-spend.params
2022-11-06 21:24:59 Loading Sapling (Output) parameters from /Applications/silentdragon.app/Contents/MacOS/sapling-output.params
2022-11-06 21:25:00 Loaded Sapling parameters in 0.420708s seconds.
2022-11-06 21:25:00 Binding RPC on address 0.0.0.0 port 18031 failed.
2022-11-06 21:25:00 HTTP: creating work queue of depth 256
2022-11-06 21:25:00 HTTP: starting 8 worker threads
2022-11-06 21:25:00 Using wallet wallet.dat
2022-11-06 21:25:00 init message: Verifying wallet...
2022-11-06 21:25:00 Using wallet wallet.dat
2022-11-06 21:25:00 init message: Verifying wallet...
2022-11-06 21:25:00 CDBEnv::Open: LogDir=/Users/fekt/Library/Application Support/Hush/HUSH3/database ErrorFile=/Users/fekt/Library/Application Support/Hush/HUSH3/db.log pathIn.(/Users/fekt/Library/Application Support/Hush/HUSH3)
2022-11-06 21:25:00 Bound to [::]:18030
2022-11-06 21:25:00 Bound to 0.0.0.0:18030
2022-11-06 21:25:00 Block index database configuration:
2022-11-06 21:25:00 * Using 1000 max open files
2022-11-06 21:25:00 * Compression is enabled
2022-11-06 21:25:00 Cache configuration:
2022-11-06 21:25:00 * Max cache setting possible 16384MiB
2022-11-06 21:25:00 * Using 384.0MiB for block index database
2022-11-06 21:25:00 * Using 40.0MiB for chain state database
2022-11-06 21:25:00 * Using 88.0MiB for in-memory UTXO set
2022-11-06 21:25:00 Opening LevelDB in /Users/fekt/Library/Application Support/Hush/HUSH3/blocks/index
2022-11-06 21:25:00 Opened LevelDB successfully
2022-11-06 21:25:00 init message: Loading block index...
2022-11-06 21:25:00 Wiping LevelDB in /Users/fekt/Library/Application Support/Hush/HUSH3/blocks/index
2022-11-06 21:25:00 Opening LevelDB in /Users/fekt/Library/Application Support/Hush/HUSH3/blocks/index
2022-11-06 21:25:00 Opened LevelDB successfully
2022-11-06 21:25:00 Wiping LevelDB in /Users/fekt/Library/Application Support/Hush/HUSH3/chainstate
2022-11-06 21:25:00 Opening LevelDB in /Users/fekt/Library/Application Support/Hush/HUSH3/chainstate
2022-11-06 21:25:00 Opened LevelDB successfully
2022-11-06 21:25:00 Wiping LevelDB in /Users/fekt/Library/Application Support/Hush/HUSH3/notarizations
2022-11-06 21:25:00 Opening LevelDB in /Users/fekt/Library/Application Support/Hush/HUSH3/notarizations
2022-11-06 21:25:00 Opened LevelDB successfully
2022-11-06 21:25:00 Initializing databases...
2022-11-06 21:25:00 init message: Verifying blocks...
2022-11-06 21:25:00 Verifying block DB... block index 55ms
2022-11-06 21:25:00 init message: Loading wallet...
2022-11-06 21:25:00 nFileVersion = 3090250
2022-11-06 21:25:00 Keys: 0 plaintext, 0 encrypted, 0 w/ metadata, 0 total
2022-11-06 21:25:00 ZKeys: 0 plaintext, 0 encrypted, 0 w/metadata, 0 total
2022-11-06 21:25:00 Performing wallet upgrade to 60000
Found hushd at "/Users/fekt/git/SilentDragon-dev-mac/build-silentdragon-Desktop_Qt_5_15_2_clang_64bit-Release/silentdragon.app/Contents/MacOS/hushd"
"Starting on Darwin: /Users/fekt/git/SilentDragon-dev-mac/build-silentdragon-Desktop_Qt_5_15_2_clang_64bit-Release/silentdragon.app/Contents/MacOS/hushd -tls=only -clientname=GoldenSandtrout"
Embedded hushd started via "/Users/fekt/git/SilentDragon-dev-mac/build-silentdragon-Desktop_Qt_5_15_2_clang_64bit-Release/silentdragon.app/Contents/MacOS/hushd"
Couldn't start hushd!
hushd at "" : QProcess::Crashed
hushd finished with code 11 , QProcess::CrashExit
Seems it's just not starting hushd.
```
Found hushd at "/Users/fekt/git/SilentDragon-dev-mac/build-silentdragon-Desktop_Qt_5_15_2_clang_64bit-Release/silentdragon.app/Contents/MacOS/hushd"
"Starting on Darwin: /Users/fekt/git/SilentDragon-dev-mac/build-silentdragon-Desktop_Qt_5_15_2_clang_64bit-Release/silentdragon.app/Contents/MacOS/hushd -tls=only -clientname=GoldenSandtrout"
Embedded hushd started via "/Users/fekt/git/SilentDragon-dev-mac/build-silentdragon-Desktop_Qt_5_15_2_clang_64bit-Release/silentdragon.app/Contents/MacOS/hushd"
Couldn't start hushd!
hushd at "" : QProcess::Crashed
hushd finished with code 11 , QProcess::CrashExit
```
Something weird with it trying to run bundled in .app on a fresh install. If there is data in HUSH3 directory after it crashes, running hushd from terminal gives this seg fault. This crash happens whether running hushd manually from bundled .app location or seperate binaries in own location. If I delete all data, I can start hushd fine from .app bundled location. I can then kill hushd in terminal and open SD fine and it runs bundled hushd fine. Seems like something with initial data creation that causes it to crash.
fekts-Mac-mini:MacOS fekt$ ./hushd
.oO Starting HUSH3 Full Node (Extreme Privacy!) with genproc=-1 notary=0
hush_args: Setting custom HUSH3 reward HUSH3=1 reward,halving,subsidy chain values...
228 234 235 236 241 nonz.5 ccenables[]
append ac_script 76a9145eb10cf64f2bab1b457f1f25e658526155928fac88ac
extralen.171 before disable bits
hush3 <- CCLIB name
hush_args: ASSETCHAINS_BLOCKTIME=150, extralen=212
HUSH raw magic=0000000000000000000000000000000000000000000000000000000000000000008100000000000000000000000000000081000000000000000000000000000000203005000000000040230e4300000000203005000000000000000000000000003e78a50000000000d088c31000000000a0d21e000000000000000000000000000200000000000000c78aa900000200000176a9145eb10cf64f2bab1b457f1f25e658526155928fac88acfeffffffffffffffffffffffffffffffffffffffffffffffffffffffefe3fdff687573683396000000 extralen=212 crc0=343844f1
hush_port: extralen=212, supply=6178674
chainparams_commandline called with port=18030
>>>>>>>>>> HUSH3: p2p.18030 rpc.18031 magic.d394d36e 3549746030 6178674 coins
chainparams_commandline: Checkpoint data loaded
hush_args.(./hushd) NOTARY_PUBKEY.() argc=1
initialized HUSH3 at 1667781465
AppInit reading config file
AppInit2: looking for asmap file at /Applications/SilentDragon.app/Contents/MacOS/asmap.dat
AppInit2: found asmap file at /Applications/SilentDragon.app/Contents/MacOS/asmap.dat
AppInit2: asmap version=d5377e5d73bfc18b924cab11f9d14badba18a4aaef45c23a538c533afaebc8e6 with 7461040 mappings
nMaxConnections 384 FD_SETSIZE.1024 nBind.1 expr.873
Attempting to obtain lock /Users/fekt/Library/Application Support/Hush/HUSH3/.lock
Creating pid file /Users/fekt/Library/Application Support/Hush/HUSH3/hushd.pid
Sapling spend: 47958396 bytes, output: 3592860 bytes
AppInitServers: start
AppInit2: Loading block index...
load blockindexDB chained 1667781466
load blockindexDB 1667781466
finished loading blocks HUSH3
OS_loadfile null size.(/Users/fekt/Library/Application Support/Hush/HUSH3/hushstate)
hush_faststateinit retval.-1
fAddressIndex.1/0 fSpentIndex.1/0 fZindex.0/0
zindex=disabled in block index
Segmentation fault: 11
Something weird with it trying to run bundled in .app on a fresh install. If there is data in HUSH3 directory after it crashes, running hushd from terminal gives this seg fault. This crash happens whether running hushd manually from bundled .app location or seperate binaries in own location. If I delete all data, I can start hushd fine from .app bundled location. I can then kill hushd in terminal and open SD fine and it runs bundled hushd fine. Seems like something with initial data creation that causes it to crash.
```
fekts-Mac-mini:MacOS fekt$ ./hushd
.oO Starting HUSH3 Full Node (Extreme Privacy!) with genproc=-1 notary=0
hush_args: Setting custom HUSH3 reward HUSH3=1 reward,halving,subsidy chain values...
228 234 235 236 241 nonz.5 ccenables[]
append ac_script 76a9145eb10cf64f2bab1b457f1f25e658526155928fac88ac
extralen.171 before disable bits
hush3 <- CCLIB name
hush_args: ASSETCHAINS_BLOCKTIME=150, extralen=212
HUSH raw magic=0000000000000000000000000000000000000000000000000000000000000000008100000000000000000000000000000081000000000000000000000000000000203005000000000040230e4300000000203005000000000000000000000000003e78a50000000000d088c31000000000a0d21e000000000000000000000000000200000000000000c78aa900000200000176a9145eb10cf64f2bab1b457f1f25e658526155928fac88acfeffffffffffffffffffffffffffffffffffffffffffffffffffffffefe3fdff687573683396000000 extralen=212 crc0=343844f1
hush_port: extralen=212, supply=6178674
chainparams_commandline called with port=18030
>>>>>>>>>> HUSH3: p2p.18030 rpc.18031 magic.d394d36e 3549746030 6178674 coins
chainparams_commandline: Checkpoint data loaded
hush_args.(./hushd) NOTARY_PUBKEY.() argc=1
initialized HUSH3 at 1667781465
AppInit reading config file
AppInit2: looking for asmap file at /Applications/SilentDragon.app/Contents/MacOS/asmap.dat
AppInit2: found asmap file at /Applications/SilentDragon.app/Contents/MacOS/asmap.dat
AppInit2: asmap version=d5377e5d73bfc18b924cab11f9d14badba18a4aaef45c23a538c533afaebc8e6 with 7461040 mappings
nMaxConnections 384 FD_SETSIZE.1024 nBind.1 expr.873
Attempting to obtain lock /Users/fekt/Library/Application Support/Hush/HUSH3/.lock
Creating pid file /Users/fekt/Library/Application Support/Hush/HUSH3/hushd.pid
Sapling spend: 47958396 bytes, output: 3592860 bytes
AppInitServers: start
AppInit2: Loading block index...
load blockindexDB chained 1667781466
load blockindexDB 1667781466
finished loading blocks HUSH3
OS_loadfile null size.(/Users/fekt/Library/Application Support/Hush/HUSH3/hushstate)
hush_faststateinit retval.-1
fAddressIndex.1/0 fSpentIndex.1/0 fZindex.0/0
zindex=disabled in block index
Segmentation fault: 11
```
It seems the underlying issue is consolidation=1 in HUSH3.conf. If I remove it then it starts fine from SD. The auto-generated config file is adding it by default. If I close SD and add it back, SD still opens up fine.
It seems the underlying issue is consolidation=1 in HUSH3.conf. If I remove it then it starts fine from SD. The auto-generated config file is adding it by default. If I close SD and add it back, SD still opens up fine.
I tested adding an ifndef to only add consolidation=1 if not Mac and it works. I then tested on a fresh install on Linux and the same crash happens with consolidation=1 so it doesn't appear to be Mac specific and affects all fresh SD installs with no existing HUSH data.
Maybe related to other recent changes with consolidation and sweeping or just nobody noticed this bug? I've never actually seen that config popup before because I've only installed SD after already using hushd from cli.
I tested adding an ifndef to only add consolidation=1 if not Mac and it works. I then tested on a fresh install on Linux and the same crash happens with consolidation=1 so it doesn't appear to be Mac specific and affects all fresh SD installs with no existing HUSH data.
It was added 2 years ago here:
https://git.hush.is/hush/SilentDragon/commit/12571798f0fe7314dc838ce528dfb5bf3e576b68
Maybe related to other recent changes with consolidation and sweeping or just nobody noticed this bug? I've never actually seen that config popup before because I've only installed SD after already using hushd from cli.
@fekt I am pretty sure this code once worked, but it looks like maybe having consolidation=1 turned on with an initial sync no longer works, such as when SD creates HUSH3.conf . Are you able to show a backtrace of the coredump from Linux?
@fekt I am pretty sure this code once worked, but it looks like maybe having `consolidation=1` turned on with an initial sync no longer works, such as when SD creates HUSH3.conf . Are you able to show a backtrace of the coredump from Linux?
[Current thread is 1 (Thread 0x7f8426b67840 (LWP 771926))]
(gdb) bt
#0 AppInit2 (threadGroup=..., scheduler=...) at ./chain.h:479
#1 0x0000557097cea17c in AppInit (argc=<optimized out>, argv=<optimized out>) at bitcoind.cpp:238
#2 0x0000557097cd3a00 in main (argc=3, argv=0x7ffd78c74638) at bitcoind.cpp:268
This is for silentdragon
[Current thread is 1 (Thread 0x7fb6b7323c40 (LWP 771913))]
(gdb) bt
#0 0x00000000004bb2ff in QtPrivate::QFunctorSlotObject<ConnectionLoader::startEmbeddedHushd()::$_11, 1, QtPrivate::List<QProcess::ProcessError>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) ()
#1 0x00007fb6ba77d5a6 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#2 0x00007fb6ba6b4431 in QProcess::errorOccurred(QProcess::ProcessError) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#3 0x00007fb6ba6b9aa6 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4 0x00007fb6ba6b9c3e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5 0x00007fb6ba77d5e0 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6 0x00007fb6ba7809df in QSocketNotifier::activated(QSocketDescriptor, QSocketNotifier::Type, QSocketNotifier::QPrivateSignal) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7 0x00007fb6ba7811db in QSocketNotifier::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8 0x00007fb6bb3bd15f in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#9 0x00007fb6ba746fca in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x00007fb6ba79f0d5 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x00007fb6b95f7e6b in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007fb6b95f8118 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007fb6b95f81cf in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007fb6ba79e51f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x00007fb6ba74598b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x00007fb6bb5b5e77 in QDialog::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#17 0x00000000004af71d in ConnectionLoader::loadConnection() ()
#18 0x00007fb6ba781552 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#19 0x00007fb6ba772f2f in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#20 0x00007fb6bb3bd15f in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#21 0x00007fb6ba746fca in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#22 0x00007fb6ba79d8e3 in QTimerInfoList::activateTimers() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#23 0x00007fb6ba79e164 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#24 0x00007fb6b95f7e6b in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#25 0x00007fb6b95f8118 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#26 0x00007fb6b95f81cf in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#27 0x00007fb6ba79e51f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#28 0x00007fb6ba74598b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#29 0x00007fb6ba74dc00 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#30 0x0000000000420ab0 in Application::main(int, char**) ()
#31 0x000000000041fb55 in main ()
On SD startup, it logs this:
Verifying sapling param files exist
Found params in QDir( "/usr/share/hush" , nameFilters = { "*" }, QDir::SortFlags( Name | IgnoreCase ) , QDir::Filters( Dirs|Files|Drives|AllEntries ) )
refreshHushdState : refreshing state
doRPC : "getinfo" QJsonValue(object, QJsonObject({"id":"42","jsonrpc":"1.0","method":"getinfo"}))
operator() : failed to connect to hushd!
Found hushd at "/home/fekt/Desktop/SilentDragon-dev-latest/build-silentdragon-Qt_5_15_2_in_PATH_qt5-Release/hushd"
"Starting on Linux: /home/fekt/Desktop/SilentDragon-dev-latest/build-silentdragon-Qt_5_15_2_in_PATH_qt5-Release/hushd -tls=only -clientname=GoldenSandtrout"
Embedded hushd started via "/home/fekt/Desktop/SilentDragon-dev-latest/build-silentdragon-Qt_5_15_2_in_PATH_qt5-Release/hushd"
Refreshing rescan data
refreshRescan
refreshRescan : no connection
doAutoConnect
Verifying sapling param files exist
Found params in QDir( "/usr/share/hush" , nameFilters = { "*" }, QDir::SortFlags( Name | IgnoreCase ) , QDir::Filters( Dirs|Files|Drives|AllEntries ) )
refreshHushdState : refreshing state
doRPC : "getinfo" QJsonValue(object, QJsonObject({"id":"42","jsonrpc":"1.0","method":"getinfo"}))
Refreshing rescan data
refreshRescan
refreshRescan : no connection
Couldn't start hushd!
11:22:26: The program has unexpectedly finished.
It seems to find hushd, says it's started, and then says it couldn't start and crashes.
Linux stack traces.
This one is for hushd
```
[Current thread is 1 (Thread 0x7f8426b67840 (LWP 771926))]
(gdb) bt
#0 AppInit2 (threadGroup=..., scheduler=...) at ./chain.h:479
#1 0x0000557097cea17c in AppInit (argc=<optimized out>, argv=<optimized out>) at bitcoind.cpp:238
#2 0x0000557097cd3a00 in main (argc=3, argv=0x7ffd78c74638) at bitcoind.cpp:268
```
This is for silentdragon
```
[Current thread is 1 (Thread 0x7fb6b7323c40 (LWP 771913))]
(gdb) bt
#0 0x00000000004bb2ff in QtPrivate::QFunctorSlotObject<ConnectionLoader::startEmbeddedHushd()::$_11, 1, QtPrivate::List<QProcess::ProcessError>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) ()
#1 0x00007fb6ba77d5a6 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#2 0x00007fb6ba6b4431 in QProcess::errorOccurred(QProcess::ProcessError) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#3 0x00007fb6ba6b9aa6 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4 0x00007fb6ba6b9c3e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5 0x00007fb6ba77d5e0 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6 0x00007fb6ba7809df in QSocketNotifier::activated(QSocketDescriptor, QSocketNotifier::Type, QSocketNotifier::QPrivateSignal) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7 0x00007fb6ba7811db in QSocketNotifier::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8 0x00007fb6bb3bd15f in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#9 0x00007fb6ba746fca in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x00007fb6ba79f0d5 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x00007fb6b95f7e6b in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007fb6b95f8118 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007fb6b95f81cf in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007fb6ba79e51f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x00007fb6ba74598b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x00007fb6bb5b5e77 in QDialog::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#17 0x00000000004af71d in ConnectionLoader::loadConnection() ()
#18 0x00007fb6ba781552 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#19 0x00007fb6ba772f2f in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#20 0x00007fb6bb3bd15f in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#21 0x00007fb6ba746fca in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#22 0x00007fb6ba79d8e3 in QTimerInfoList::activateTimers() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#23 0x00007fb6ba79e164 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#24 0x00007fb6b95f7e6b in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#25 0x00007fb6b95f8118 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#26 0x00007fb6b95f81cf in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#27 0x00007fb6ba79e51f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#28 0x00007fb6ba74598b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#29 0x00007fb6ba74dc00 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#30 0x0000000000420ab0 in Application::main(int, char**) ()
#31 0x000000000041fb55 in main ()
```
On SD startup, it logs this:
```
Verifying sapling param files exist
Found params in QDir( "/usr/share/hush" , nameFilters = { "*" }, QDir::SortFlags( Name | IgnoreCase ) , QDir::Filters( Dirs|Files|Drives|AllEntries ) )
refreshHushdState : refreshing state
doRPC : "getinfo" QJsonValue(object, QJsonObject({"id":"42","jsonrpc":"1.0","method":"getinfo"}))
operator() : failed to connect to hushd!
Found hushd at "/home/fekt/Desktop/SilentDragon-dev-latest/build-silentdragon-Qt_5_15_2_in_PATH_qt5-Release/hushd"
"Starting on Linux: /home/fekt/Desktop/SilentDragon-dev-latest/build-silentdragon-Qt_5_15_2_in_PATH_qt5-Release/hushd -tls=only -clientname=GoldenSandtrout"
Embedded hushd started via "/home/fekt/Desktop/SilentDragon-dev-latest/build-silentdragon-Qt_5_15_2_in_PATH_qt5-Release/hushd"
Refreshing rescan data
refreshRescan
refreshRescan : no connection
doAutoConnect
Verifying sapling param files exist
Found params in QDir( "/usr/share/hush" , nameFilters = { "*" }, QDir::SortFlags( Name | IgnoreCase ) , QDir::Filters( Dirs|Files|Drives|AllEntries ) )
refreshHushdState : refreshing state
doRPC : "getinfo" QJsonValue(object, QJsonObject({"id":"42","jsonrpc":"1.0","method":"getinfo"}))
Refreshing rescan data
refreshRescan
refreshRescan : no connection
Couldn't start hushd!
11:22:26: The program has unexpectedly finished.
```
It seems to find hushd, says it's started, and then says it couldn't start and crashes.
@fekt I ran into a coredump while working on randomx that I think is actually the same issue causing this. Try the latest commit in the hush3 dev branch and see if this still happens. The code was calling pindex->GetHeight() but pindex was NULL.
@fekt I ran into a coredump while working on randomx that I think is actually the same issue causing this. Try the latest commit in the hush3 dev branch and see if this still happens. The code was calling `pindex->GetHeight()` but `pindex` was NULL.
Still get a crash on Mac, but it wasn't showing me stack trace and need to get one. No crash on Linux now but instead I get authenication failed. If there is no existing HUSH3.conf, SD creates one with really short user/pass like attached. Not sure if there is a check in SD for length or something that thinks it's invalid.
Still get a crash on Mac, but it wasn't showing me stack trace and need to get one. No crash on Linux now but instead I get authenication failed. If there is no existing HUSH3.conf, SD creates one with really short user/pass like attached. Not sure if there is a check in SD for length or something that thinks it's invalid.
It has a value for pwalletMain->consolidationInterval. chainActive.Tip()->GetHeight() crashes.
Crashes here: https://git.hush.is/hush/hush3/src/branch/dev/src/init.cpp#L2045
It has a value for pwalletMain->consolidationInterval. chainActive.Tip()->GetHeight() crashes.
Actually I do still get a crash for hushd on Linux too. It just wasn't causing SD to crash now. I think the easiest way to reproduce is to move or delete all data except for HUSH3.conf, add consolidation=1, and then run hushd from cli. I don't seem to get this crash in 1.3.0 so may only be related to changes in dev branches.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 AppInit2 (threadGroup=..., scheduler=...) at ./chain.h:479
479 return this->chainPower.nHeight;
[Current thread is 1 (Thread 0x7f5f9992b840 (LWP 446988))]
(gdb) bt
#0 AppInit2 (threadGroup=..., scheduler=...) at ./chain.h:479
#1 0x000055ea153d832c in AppInit (argc=<optimized out>, argv=<optimized out>) at bitcoind.cpp:238
#2 0x000055ea153c1bb0 in main (argc=1, argv=0x7ffedddb6308) at bitcoind.cpp:268
Easiest temp fix might be to not add consolidation=1 in SD at all. If you create fresh wallet with hushd from command line, it does not add consolidation=1.
Actually I do still get a crash for hushd on Linux too. It just wasn't causing SD to crash now. I think the easiest way to reproduce is to move or delete all data except for HUSH3.conf, add consolidation=1, and then run hushd from cli. I don't seem to get this crash in 1.3.0 so may only be related to changes in dev branches.
```
Program terminated with signal SIGSEGV, Segmentation fault.
#0 AppInit2 (threadGroup=..., scheduler=...) at ./chain.h:479
479 return this->chainPower.nHeight;
[Current thread is 1 (Thread 0x7f5f9992b840 (LWP 446988))]
(gdb) bt
#0 AppInit2 (threadGroup=..., scheduler=...) at ./chain.h:479
#1 0x000055ea153d832c in AppInit (argc=<optimized out>, argv=<optimized out>) at bitcoind.cpp:238
#2 0x000055ea153c1bb0 in main (argc=1, argv=0x7ffedddb6308) at bitcoind.cpp:268
```
Easiest temp fix might be to not add consolidation=1 in SD at all. If you create fresh wallet with hushd from command line, it does not add consolidation=1.
Default HUSH3.conf created by hushd
```
rpcuser=user4286974887
rpcpassword=passe0a7149ff03dadcf93de466c874968155d6d9558e69983422986e62ef16c95c9a7
rpcport=18031
server=1
txindex=1
rpcworkqueue=4096
rpcallowip=127.0.0.1
rpcbind=127.0.0.1
```
Default HUSH3.conf created by SD
```
server=1
rpcuser=hush
rpcpassword=qmSU
rpcport=18031
txindex=1
addressindex=1
spentindex=1
timestampindex=1
rpcworkqueue=256
rpcallowip=127.0.0.1
consolidation=1
tls=only
```
@duke Yes chainActive.Height() works. I tested same change last night but wasn't sure if it would break anything for when consolidation and sweep runs. I think it set interval to every 24 blocks by default becauses chainActive.Height() returns -1 on fresh install but will test again and check if consolidation/sweep runs.
@duke Yes chainActive.Height() works. I tested same change last night but wasn't sure if it would break anything for when consolidation and sweep runs. I think it set interval to every 24 blocks by default becauses chainActive.Height() returns -1 on fresh install but will test again and check if consolidation/sweep runs.
@duke I figured it was better to have a slightly off nextSweep/nextConsolidation height than coredumping. The first time things run, that value will be updated with a correct value, I think
@duke I figured it was better to have a slightly off nextSweep/nextConsolidation height than coredumping. The first time things run, that value will be updated with a correct value, I think
It does use 24 but I don't think it's a big deal. Anything better than a crash. It is still syncing from scratch. If I restart SD, then set nextConsolidation= shows what looks like the height it's currently synced at + interval so I think it's fine.
It does use 24 but I don't think it's a big deal. Anything better than a crash. It is still syncing from scratch. If I restart SD, then `set nextConsolidation=` shows what looks like the height it's currently synced at + interval so I think it's fine.
I did not notice this until now due to user reporting issue because I created wallet and synced with hushd from terminal initially. On a completely fresh install, SD opens up this popup and then crashes when clicking OK. Trying to open again crashes again with same
Performing wallet upgrade to 60000in debug.log. If you start hushd manually and then open SD, it works fine. Not sure if there is some Mac specific code causing this issue or possibly an issue with the .dmg and packaged bins, but needs further testing.debug.log
SilentDragon.log
Seems it's just not starting hushd.
Something weird with it trying to run bundled in .app on a fresh install. If there is data in HUSH3 directory after it crashes, running hushd from terminal gives this seg fault. This crash happens whether running hushd manually from bundled .app location or seperate binaries in own location. If I delete all data, I can start hushd fine from .app bundled location. I can then kill hushd in terminal and open SD fine and it runs bundled hushd fine. Seems like something with initial data creation that causes it to crash.
Left is running SD (crashes). Right is starting hushd in silentdragon.app from terminal (works).
https://www.diffchecker.com/SXi3Incu/
Stack trace:
It seems the underlying issue is consolidation=1 in HUSH3.conf. If I remove it then it starts fine from SD. The auto-generated config file is adding it by default. If I close SD and add it back, SD still opens up fine.
@fekt sounds weird. If you want to change the code to not add in
consolidation=1for Macs, that sounds fine.I tested adding an ifndef to only add consolidation=1 if not Mac and it works. I then tested on a fresh install on Linux and the same crash happens with consolidation=1 so it doesn't appear to be Mac specific and affects all fresh SD installs with no existing HUSH data.
It was added 2 years ago here:
12571798f0Maybe related to other recent changes with consolidation and sweeping or just nobody noticed this bug? I've never actually seen that config popup before because I've only installed SD after already using hushd from cli.
@fekt I am pretty sure this code once worked, but it looks like maybe having
consolidation=1turned on with an initial sync no longer works, such as when SD creates HUSH3.conf . Are you able to show a backtrace of the coredump from Linux?@fekt I was close to making a new SD release but it sounds like we should try to fix this bug before that. Let me know how I can help.
Linux stack traces.
This one is for hushd
This is for silentdragon
On SD startup, it logs this:
It seems to find hushd, says it's started, and then says it couldn't start and crashes.
@fekt I ran into a coredump while working on randomx that I think is actually the same issue causing this. Try the latest commit in the hush3 dev branch and see if this still happens. The code was calling
pindex->GetHeight()butpindexwas NULL.Still get a crash on Mac, but it wasn't showing me stack trace and need to get one. No crash on Linux now but instead I get authenication failed. If there is no existing HUSH3.conf, SD creates one with really short user/pass like attached. Not sure if there is a check in SD for length or something that thinks it's invalid.
Crashes here: https://git.hush.is/hush/hush3/src/branch/dev/src/init.cpp#L2045
It has a value for pwalletMain->consolidationInterval. chainActive.Tip()->GetHeight() crashes.
Actually I do still get a crash for hushd on Linux too. It just wasn't causing SD to crash now. I think the easiest way to reproduce is to move or delete all data except for HUSH3.conf, add consolidation=1, and then run hushd from cli. I don't seem to get this crash in 1.3.0 so may only be related to changes in dev branches.
Easiest temp fix might be to not add consolidation=1 in SD at all. If you create fresh wallet with hushd from command line, it does not add consolidation=1.
Default HUSH3.conf created by hushd
Default HUSH3.conf created by SD
@fekt I believe my latest commit to hush3
devbranch will fix this@duke Yes chainActive.Height() works. I tested same change last night but wasn't sure if it would break anything for when consolidation and sweep runs. I think it set interval to every 24 blocks by default becauses chainActive.Height() returns -1 on fresh install but will test again and check if consolidation/sweep runs.
@duke I figured it was better to have a slightly off nextSweep/nextConsolidation height than coredumping. The first time things run, that value will be updated with a correct value, I think
It does use 24 but I don't think it's a big deal. Anything better than a crash. It is still syncing from scratch. If I restart SD, then
set nextConsolidation=shows what looks like the height it's currently synced at + interval so I think it's fine.this seems to be fixed, closing