Let us know which version you tested on which operating system. If you find an issue, please search Github for known issues first and then open a new Github issue.
See Release Notes for a list of changes, and testing reports for earlier releases (v0.17.1), for an idea what to test.
Sjors
commented at 2:28 pm on March 7, 2019:
member
tACK v0.18.0rc1 on macOS 10.14.3:
tested installing from (signed) DMG
tested loading wallets
testing sending coins
testing receiving coins (notification)
fanquake added the label
Tests
on Mar 7, 2019
fanquake added this to the milestone 0.18.0
on Mar 7, 2019
kiv06041992
commented at 7:03 am on March 8, 2019:
none
promag
commented at 8:13 am on March 8, 2019:
member
kiv06041992
commented at 10:59 am on March 8, 2019:
none
OS: Ubuntu 18.04.2 LTS - x64
CPU: AMD® Fx(tm)-6100 six-core processor × 6
Memory: 11.6гб
and russian language
0.17.1 is working stable
If you need you may connect towards my computer via TeamViewer
makoting
commented at 4:25 am on March 9, 2019:
none
bitcoind v0.18.0rc1 is using 100% CPU resources while syncing the blocks. Top, the processes monitoring utility, shows bitcoind-opencon thread is the CPU hog. Ran with -proxy=127.0.0.1:9050.
Debian 9.8 x86_64 Linux GNU as guest VM
VirtualBox 6.0.4, Windows 10 as host
Intel Core i5-8250U CPU
fanquake pinned this
on Mar 10, 2019
hebasto
commented at 6:15 pm on March 10, 2019:
member
@kiv06041992
I can try reproduce an issue on Ubuntu with Russian language. Which desktop environment do you use?
Let us know your bitcoin.conf and your command-line options if any as well.
On the other hand, you can submit a new issue.
jasonzhouu
commented at 2:42 am on March 11, 2019:
none
I looked debug.log and saw it.
`2019-03-07T20:04:10Z GUI: Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt.
You must not let any exception whatsoever propagate through Qt code.
If that is not possible, in Qt 5 you must at least reimplement
QCoreApplication::notify() and catch all exceptions there.
2019-03-07T20:04:10Z
EXCEPTION: N5boost10filesystem16filesystem_errorE
filesystem::recursive_directory_iterator directory error: Отказано в доступе
bitcoin in Runaway exception`
After this message bitcoin core crashed.
MarcoFalke
commented at 2:19 pm on March 11, 2019:
member
@kiv06041992 Could you please share the lines before that in the debug.log?
promag
commented at 2:30 pm on March 11, 2019:
member
MarcoFalke
commented at 5:17 pm on March 11, 2019:
member
Does this also happen if you run bitcoind? If so, could you please run bitcoind in gdb to get a stack trace of the exception?
kiv06041992
commented at 5:22 pm on March 11, 2019:
none
@promag
I download
bitcoin-0.18.0rc1-x86_64-linux-gnu.tar.gz https://bitcoincore.org/bin/bitcoin-core-0.18.0/test.rc1/
and put
bitcoin-0.18.0rc1-x86_64-linux-gnu.tar.gz/bitcoin-0.18.0rc1/bin/bitcoin-qt
in
/usr/local/bin and run him ./bitcoin-qt
I did not use build.
Only 0.18.0 crashed. v0.17.1 work perfectly
Sorry. I bad speak english but want help
promag
commented at 5:34 pm on March 11, 2019:
member
Please run bitcoin-qt -nowallet and see if the error occurs.
kiv06041992
commented at 6:57 pm on March 11, 2019:
none
@promag I ran bitcoin-qt -nowallet and waiting
@MarcoFalke I did not run bitcoind. If will bitcoin-qt -nowallet crash i will try run bitcoind in gdb
promag
commented at 10:37 pm on March 11, 2019:
member
I’ve managed to reproduce the problem (or apparently) in macos:
0# 1. create directory for -walletdir without read access 1mkdir /tmp/foo && chmod a-r /tmp/foo
2 3# 2. download and mount https://bitcoincore.org/bin/bitcoin-core-0.18.0/test.rc1/bitcoin-0.18.0rc1-osx.dmg 4 5# 3. run bitcoin-qt and should print a error, but continues running 6/Volumes/Bitcoin-Core/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt -regtest -walletdir=/tmp/foo
7/private/tmp/foo: Permission denied
8 9# 4. go to File -> Open Wallet and should segfault10EXCEPTION: N5boost10filesystem16filesystem_errorE
11boost::filesystem::directory_iterator::construct: Permission denied: "/private/tmp/foo"12bitcoin in Runaway exception
I’m working on a fix.
MarcoFalke
commented at 3:20 pm on March 12, 2019:
member
That fixes the underlying wallet issue, but it seems there is still the gui issue:
0Qt has caught an exception thrown from an event handler. Throwing
1exceptions from an event handler is not supported in Qt.
2You must not let any exception whatsoever propagate through Qt code.
3If that is not possible, in Qt 5 you must at least reimplement
4QCoreApplication::notify() and catch all exceptions there.
promag
commented at 3:42 pm on March 12, 2019:
member
must not let any exception whatsoever propagate
@MarcoFalke the fix does this?
kiv06041992
commented at 6:09 pm on March 12, 2019:
none
PureOS distribution of Linux Debian 4.19.16-1 (2019-01-17) x86_64 GNU/Linux
tested installing
tested loading wallets
tested running bin/bitcoind with nearly up-to-date mainnet blocks, synced rapidly without issue
tested running bin/bitcoin-qt, verifying debug windows info/console/network/peers, and running cli commands in the console
jonatack
commented at 1:45 pm on March 14, 2019:
member
Idem for compiling v0.18.0rc1 tagged branch from source.
jonatack referenced this in commit
ff414288b5
on Mar 16, 2019
MarcoFalke
commented at 1:54 pm on March 18, 2019:
member
You can also report issues you found here
I’d advise against reporting issues here. They should go in their own report. Otherwise it is hard to follow-up on reports when everything is in the same thread.
bitcoind compiled from source, tested, used on mainnet with regular p2p activity
reindexed from scratch
txindex deleted and rebuilt from scratch
farrilis
commented at 4:51 pm on March 25, 2019:
none
CPU maxing out using 18 rc2 binaries, Debian 9.8, using prune=550 with bitcoin-qt
importmulti -ing several hundred watch only addresses to a non-default wallet apparently triggered this, but subsequently executing with -disablewallet exhibits the same issue (CPU spikes to 100% for 5-10s every 30s)
No such CPU spikes using 0.17.1 (either loading -wallet=mywatchonly or -disablewallet). 0.18.0rc2 does exhibit the described spikes with either -wallet=mywatchonly or -disablewallet. Hence maybe a prune=550 issue.
MarcoFalke
commented at 5:00 pm on March 25, 2019:
member
@farrilis Could you determine which thread is using the CPU? (Maybe with top or htop)
Alternatively get a thread apply all bt in gdb when the spike happens to see the exact code location.
farrilis
commented at 6:26 pm on March 25, 2019:
none
$ gdb ./bitcoin-qt
(gdb) thread apply all bt
(gdb) run
Open another terminal window with gdb --args ./bitcoin-qt
** Type run in (gdb)
** Watch the CPU usage of the opencon thread in the htop window
** Hit CTRL+C in (gdb) when it is at 100%
** Type thread apply all bt in (gdb)
jonatack referenced this in commit
b9bdfe3e07
on Mar 28, 2019
farrilis
commented at 10:28 am on March 29, 2019:
none
Ok:
0Thread 22 (Thread 0x7fff45fb0700 (LWP 2310)):
1[#0](/bitcoin-bitcoin/0/) 0x00007ffff637e981 in __GI_ppoll (fds=0x555557c58608, nfds=1, timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:39
2[#1](/bitcoin-bitcoin/1/) 0x00005555562934c1 in ?? ()
3[#2](/bitcoin-bitcoin/2/) 0x0000555556294a99 in ?? ()
4[#3](/bitcoin-bitcoin/3/) 0x000055555624245f in ?? ()
5[#4](/bitcoin-bitcoin/4/) 0x00005555560e2956 in ?? ()
6[#5](/bitcoin-bitcoin/5/) 0x00005555560e4c25 in ?? ()
7[#6](/bitcoin-bitcoin/6/) 0x00007ffff79bb4a4 in start_thread (arg=0x7fff45fb0700) at pthread_create.c:456
8[#7](/bitcoin-bitcoin/7/) 0x00007ffff6387d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
910Thread 21 (Thread 0x7fff467b1700 (LWP 2309)):
11[#0](/bitcoin-bitcoin/0/) 0x00007ffff637e981 in __GI_ppoll (fds=0x7fff24000ac8, nfds=1, timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:39
12[#1](/bitcoin-bitcoin/1/) 0x00005555562934c1 in ?? ()
13[#2](/bitcoin-bitcoin/2/) 0x0000555556294a99 in ?? ()
14[#3](/bitcoin-bitcoin/3/) 0x000055555624245f in ?? ()
15[#4](/bitcoin-bitcoin/4/) 0x00005555560e2956 in ?? ()
16[#5](/bitcoin-bitcoin/5/) 0x00005555560e4c25 in ?? ()
17[#6](/bitcoin-bitcoin/6/) 0x00007ffff79bb4a4 in start_thread (arg=0x7fff467b1700) at pthread_create.c:456
18[#7](/bitcoin-bitcoin/7/) 0x00007ffff6387d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
1920Thread 20 (Thread 0x7fff47420700 (LWP 2308)):
21[#0](/bitcoin-bitcoin/0/) 0x00007ffff637e981 in __GI_ppoll (fds=0x7fff20000ac8, nfds=1, timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:39
22[#1](/bitcoin-bitcoin/1/) 0x00005555562934c1 in ?? ()
23[#2](/bitcoin-bitcoin/2/) 0x0000555556294a99 in ?? ()
24[#3](/bitcoin-bitcoin/3/) 0x000055555624245f in ?? ()
25[#4](/bitcoin-bitcoin/4/) 0x00005555560e2956 in ?? ()
26[#5](/bitcoin-bitcoin/5/) 0x00005555560e4c25 in ?? ()
27[#6](/bitcoin-bitcoin/6/) 0x00007ffff79bb4a4 in start_thread (arg=0x7fff47420700) at pthread_create.c:456
28[#7](/bitcoin-bitcoin/7/) 0x00007ffff6387d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
2930Thread 19 (Thread 0x7fff47c21700 (LWP 2307)):
31[#0](/bitcoin-bitcoin/0/) pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
32[#1](/bitcoin-bitcoin/1/) 0x000055555588049b in ?? ()
33[#2](/bitcoin-bitcoin/2/) 0x000055555586f885 in ?? ()
34[#3](/bitcoin-bitcoin/3/) 0x000055555588effb in ?? ()
35[#4](/bitcoin-bitcoin/4/) 0x0000555556afccbf in ?? ()
36[#5](/bitcoin-bitcoin/5/) 0x00007ffff79bb4a4 in start_thread (arg=0x7fff47c21700) at pthread_create.c:456
37[#6](/bitcoin-bitcoin/6/) 0x00007ffff6387d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
3839Thread 18 (Thread 0x7fff48422700 (LWP 2306)):
40[#0](/bitcoin-bitcoin/0/) 0x00007ffff79c451f in __libc_recv (fd=42, buf=0x7fff48420ecc, n=4, flags=0) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:28
41[#1](/bitcoin-bitcoin/1/) 0x0000555555be958a in ?? ()
42[#2](/bitcoin-bitcoin/2/) 0x0000555555beee50 in ?? ()
43[#3](/bitcoin-bitcoin/3/) 0x0000555555bf0525 in ?? ()
44[#4](/bitcoin-bitcoin/4/) 0x000055555588af61 in ?? ()
45[#5](/bitcoin-bitcoin/5/) 0x000055555588b510 in ?? ()
46[#6](/bitcoin-bitcoin/6/) 0x000055555588c285 in ?? ()
47[#7](/bitcoin-bitcoin/7/) 0x00005555558948c7 in ?? ()
48[#8](/bitcoin-bitcoin/8/) 0x000055555586f885 in ?? ()`
jonatack referenced this in commit
dba0fbb2f1
on Mar 29, 2019
MarcoFalke
commented at 4:05 pm on March 29, 2019:
member
Hmm, looks like you are missing the debug symbols. You might want to try to download them into the same folder where your bitcoin-qt is located and then start gdb again (it should then print something like Reading symbols from ./bin/bitcoin-qt...Reading symbols from ./bin/bitcoin-qt.dbg...done.
0wget https://github.com/achow101/bitcoin/releases/download/v0.18.0rc2/bitcoin-0.18.0rc2-x86_64-linux-gnu-debug.tar.gz
1echo '438c107c985c88fa7e2eec13f7c03cdfedf079698ef7ea07597962fad080b954 bitcoin-0.18.0rc2-x86_64-linux-gnu-debug.tar.gz' | sha256sum --check
2# untar and repeat above steps with gdb
farrilis
commented at 3:47 pm on March 31, 2019:
none
result:
0Thread1"bitcoin-qt" received signal SIGINT, Interrupt.10x00007ffff637e981in __GI_ppoll (fds=0x555557f53618, nfds=2, timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:39239../sysdeps/unix/sysv/linux/ppoll.c: No such file or directory.
promag
commented at 11:06 pm on April 1, 2019:
member
Hence maybe a prune=550 issue.
@farrilis but what happens without prune in 0.18?
farrilis
commented at 11:03 am on April 2, 2019:
none
without prune I don’t see this issue using 0.18. My full NETWORK_NODE is in a different VM.
bitcoinhodler
commented at 5:33 am on April 3, 2019:
contributor
In 0.18.0rc3, the new getrpcinfo returns JSON with a key “duration”, but there is nothing in that key name or in bitcoin-cli help getrpcinfo that tells me what time units it’s counting in. Is that duration in seconds? Milliseconds? I have no idea.
nitramiz
commented at 4:41 pm on April 3, 2019:
none
tACK 0.18.0rc2 on MacOS 10.13.6:
Built a docker image for bitcoind (blockstream/bitcoind@sha256:4c072542ff148b99467cab32756c3c2cdd1e05a8b8e30c2b1fe28a9ca90ec0b8) from the binary at bitcoincore.org (x86_64-linux-gnu.tar.gz)
Ran with prune=10000 and dbcache=2500
Synced testnet from scratch and reindexed once
Tested createfunded/decode/finalize PSBT, importmulti and broadcasting a tx (with the help of HWI and a Trezor)
promag
commented at 11:13 pm on April 8, 2019:
member
@bitcoinhodler it is microseconds. getrpcinfo help message was completed in #15754.
jonatack
commented at 12:39 pm on April 11, 2019:
member
Linux Debian 4.19.28-2 (2019-03-15) x86_64 GNU/Linux
tested installing
tested loading wallets
tested bitcoind with nearly up-to-date mainnet blocks, synced rapidly without issue
tested bitcoin-qt, verifying debug file, windows info/console/network/peers, and running cli commands in the console
jonatack referenced this in commit
04415de8ed
on Apr 16, 2019
jonatack referenced this in commit
a684f9a4db
on Apr 16, 2019
jonatack referenced this in commit
5eb28bb3a0
on Apr 16, 2019
jonatack referenced this in commit
a68cbce1e1
on Apr 16, 2019
jonatack referenced this in commit
06d28351e0
on Apr 16, 2019
jonatack referenced this in commit
d9f7a33dc2
on Apr 16, 2019
jonatack referenced this in commit
3c3d801f3c
on Apr 16, 2019
jonatack referenced this in commit
3fd0cf303e
on Apr 16, 2019
jonatack referenced this in commit
80ad32c519
on Apr 16, 2019
cfromknecht
commented at 2:29 am on April 17, 2019:
none
A user recently reported https://github.com/lightningnetwork/lnd/issues/2961 in testing lnd with an 0.18-ish build. I was able to locate #13541 which introduces a breaking change to the sendrawtransaction API, preventing lnd from publishing transactions with the following error:
Second argument must be numeric (maxfeerate) and no longer supports a boolean. To allow a transaction with high fees, set maxfeerate to 0.
In skimming the draft release notes I could not find anything mentioning this change, is it worth adding?
The change affects all prior versions of lnd including 0.6 tagged today, so we’ll be working on an update to our rpcclient to support the new numeric value and support downgrading to the boolean value on pre-0.18 nodes in our next 0.6.1 release.
(happy to make a separate issue if there’s more to be done besides updating release notes)
fanquake
commented at 2:45 am on April 17, 2019:
member
@cfromknecht#13541 isn’t part of v0.18, (it’s currently in master and will be released in v0.19), so I’d assume that user is running some version of master they’ve compiled themselves. Although looking at the related issue, they originally said they were running v0.17.1, so it’s a bit hard to tell?
cfromknecht
commented at 3:08 am on April 17, 2019:
none
#13541 isn’t part of v0.18, (it’s currently in master and will be released in v0.19)
oh i see, that then makes perfect sense why i couldn’t find it in the release notes :)
thank you for the clarification, that should give us plenty of time to support the change from our end
they originally said they were running v0.17.1
i presume it’s because the versions may not be bumped in their branch, but yes it is unclear
molxyz
commented at 5:50 pm on April 23, 2019:
none
@Sjors Hi, thank you for this thread. I’m also trying to test 0.18.0rc4.
I have a question if anyone knows what the button Main Window on bitcoin-qt is for? I am running v0.18.0rc4, started seeing this button since last RC version, could not get it to do anything, thought it would be fixed in RC4 but still the same. I have tried by going from one window to another and clicked on this button Main Window but it doesn’t do anything so I am wondering why it’s there.
I compiled the software from source on WSL using bitcoin guide https://github.com/bitcoin/bitcoin/blob/master/doc/build-windows.md and running it on Windows 10.
Sjors
commented at 6:13 pm on April 23, 2019:
member
@molxyz please create a new issue for that; this issue is for finding potential release blocking problems. I think it was introduced here.
molxyz
commented at 8:01 pm on April 23, 2019:
none
This is a metadata mirror of the GitHub repository
bitcoin/bitcoin.
This site is not affiliated with GitHub.
Content is generated from a GitHub metadata backup.
generated: 2024-12-27 03:12 UTC
This site is hosted by @0xB10C More mirrored repositories can be found on mirror.b10c.me