< mryandao>
heya, while running bitcoind in docker, i tried to symlink debug.log to /dev/stderr and bitcoind crashed when a boost function tried to read the path, is that expected behaviour?
< NicolasDorier>
Running bitcoin-core-0.15.0/test.rc3 on one of my server, getting "2017-09-14 06:55:48 socket send error The operation completed successfully. (0)" in logs _without_ debug=net. Then the connection drop to the peer. My peer is a NBitcoin peer, and I could not reproduce the error on the same 0.15.0/test.rc3 running on my machine.
< NicolasDorier>
"socket send error The operation completed successfully. (0)", interesting message at least...
< NicolasDorier>
mmh I doubt the bug comes from bitcoin core actually
< bitcoin-git>
[bitcoin] MeshCollider opened pull request #11326: Fix crash on shutdown with invalid wallet (master...201709_shutdown_crash) https://github.com/bitcoin/bitcoin/pull/11326
< meshcollider>
thats such a small fix it doesn't even feel right to make a whole PR lol
< earlz>
How exactly do you debug the bitcoin-qt on 64bit windows? I know the gitian builds produce both the binaries and debug symbols, but not sure what the best way to debug a crash is
< wumpus>
earlz: the debug symbols can be used in combination with the stack trace and a memory map to find out what symbol was involved. I don't know of any way to do debugging *on* windows sanely, there's a mingw gdb but I don't think it works very well
< promag>
wdyt return txid in signrawtransaction? (at least if complete)
< promag>
there is this pattern decoderaw(signraw().hex).txid
< promag>
could be simplified to signraw().txid
< wumpus>
could be, though I always run decoderaw after signraw anyhow, to check the transaction one last time before broadcasting it
< wumpus>
so it wouldn't help me at least - but if you think many would be helped by having txid on signrawtransaction output object why not open a PR
< wumpus>
also, sendrawtransaction(hex) returns the txid - so you really need the txid before broadcasting the transaction?
< wumpus>
or is this useful if you use an alternative way to broadcast transactions
< bitcoin-git>
bitcoin/master 96d91b7 Wladimir J. van der Laan: contrib: Ignore historical release notes for whitespace check...
< NicolasDorier>
how to remove DEBUG_LOCKORDER ? I tried to compile withount --enable-debug, but no luck it see;s
< NicolasDorier>
meh I must have screwed up somewhere... will redeploy
< wumpus>
it's --enable-debug that adds it, so rebuilding without it (you'd need to 'make clean' too) will get rid of it
< NicolasDorier>
yeah sorry, I messed up by replacing the wrong bitcoind on my server :/
< NicolasDorier>
so actually I did not tried https://github.com/bitcoin/bitcoin/pull/11126 yet. But the path of the locks is different from the PR so I guess this is different error.
< NicolasDorier>
filed an issue
< MarcoFalke>
15000 commits. This thing explodes 🎉
< wumpus>
interesting, it probably does some update coalescing on the background. I've personally never noticed tmux making things slower, but I don't have any fancy plugins iether
< luke-jr>
right
< bitcoin-git>
[bitcoin] danra opened pull request #11330: Trivial: Fix comments for DEFAULT_WHITELIST[FORCE]RELAY (master...patch-10) https://github.com/bitcoin/bitcoin/pull/11330
< achow101>
if anyone sees any issue remotely like #11171, please get the GUI settings (from windows registry or from ~/.config/Bitcoin/Bitcoin-Qt.conf) before doing -resetguisettings
< achow101>
I would like to see what the gui settings are before they are reset as that should give a clue as to how that crash is happening
< wumpus>
yes that would be very useful to know
< wumpus>
will you ask in the issue too?
< achow101>
yep, asked
< achow101>
I didn't realize someone else was experiencing the same problem. otherwise I would have asked them for their gui settings earlier, but they already reset them
< gmaxwell>
Has anyone encountered this on Linux?
< achow101>
gmaxwell: I don't think so
< ryanofsky>
BlueMatt got a report from someone yesterday using linux
< wumpus>
so from achow101's analysis it looks like something to do with the proxy configuration? that could be the case ,proxy can be set from the gui settings
< BlueMatt>
yea, someone complaining that 0.15 on the ppa was busted
< BlueMatt>
his response to me claimed he assumed it was proxy
< BlueMatt>
i asked for more details but havent heard back yet (to try to confirm it if possible)
< achow101>
I think it has to do with the proxy setting although I couldn't think of a proxy string that would replicate the problem
< wumpus>
if that is true, though, it should be possible to trigger it from the command line too, as the proxy simply gets passed in in a similar way
< wumpus>
yes exactly then it will be some string that crashes it
< wumpus>
apparently starting with 0.15 branch
< achow101>
well I tried a lot of weird strings and couldn't get anything to crash it :/
< achow101>
I got it to crash after it all loaded and I tried to modify the settings though. There's an open issue for that
< wumpus>
I don't remember if there were any proxy handling changes for 0.15
< gmaxwell>
thats it's a crash limits the number of possibiltty.
< gmaxwell>
er possibilities.
< gmaxwell>
Merge #9774: Enable host lookups for -proxy and -onion parameters
< wumpus>
if it's something in paymentserver crashing, it's not the lookup itself that crashes it, but something in the transfer of the proxy address to a qt structure
< gmaxwell>
well for example, I wonder if Lookup would crash with a e.g. 0xff input. otherwise I don't see how the lookup change could be it
< gmaxwell>
(or maybe a truncated multibyte character)
< wumpus>
it happens after the argument parsing though
< wumpus>
in the log in 11171 it's even handling peers already
< gmaxwell>
the obvious way to try to repro is to get these things set in the registry, then edit the registry manually to set the keys to empty strings.
< achow101>
gmaxwell: been there done that. A lot of invalid things are caught that makes it fail to start entirely (throws initerror)
< wumpus>
yes, it help so much to have an example of a failing config
< harrymm>
i got matt's ppa to my ubuntu 17.04 system when it was available. i had the gui crash you're talking about and got it working with -resetguisettings.
< harrymm>
i still have the processed core dump if that helps ya.
< gmaxwell>
you have a core dump!
< achow101>
harding: it would be better to have your gui config
< harrymm>
it actually said the seg was SIGSEGV at QAbstractButton:setChecked(bool) from libQtGui.so.4.
< harrymm>
yep. i'm not sure how to analyse it. it's a whoopsie thing.
< harrymm>
gdb doesn't do the job. sorry i'm not too skillful at this :)
< harrymm>
it was produced when i allowed it to send the bug info to launchpad trackers (I thought)
< BlueMatt>
harrymm: I mean what settings do you recall having? custom datadir, encrypted wallet, selected different buttons for fees in the send tab.....?
< BlueMatt>
minimize to tray?
< harrymm>
yes to all of those iirc
< harrymm>
i had a backup i made during this process but cleaned it out today when the thing finally worked. :(
< gmaxwell>
harrymm: can you get a backtrace from it? gdb -c corefile ./path-to/bitcoin-qt then "thread apply all bt full"
< harrymm>
i'll have a shot...
< harrymm>
no. that gives me the same result i got before. it doesn't recognize the apport/whoopsie processed file
< gmaxwell>
okay I don't know what that does it it.
< wumpus>
it's possible to extract a gdb core dump from the processed file, don't remember the steps though
< harrymm>
i couldn't find out how to load it locally either. but the file info was sent off to a bug tracker at the time (severl times in fact). launchpad should have it.
< harrymm>
tho. this file is 100MB. i'm sure not that much was in the bug report :)
< harrymm>
source "0x8(%rdi)" (0x00000008) not located in a known VMA region (needed readable region)!
< harrymm>
destination "%rbx" ok
< wumpus>
can you pastebin the output of: <gmaxwell> harrymm: can you get a backtrace from it? gdb -c corefile ./path-to/bitcoin-qt then "thread apply all bt full"
< harrymm>
segvreason: reading NULL VMA
< harrymm>
i can't make gdb process this thing
< wumpus>
I guess something called setChecked on a NULL pointer
< wumpus>
there should be a corefile between those unpacked files, that works with gdb in that way
< harrymm>
oh. wait..
< harrymm>
haha. i missed that CoreDump file. Ok. I've got gdb opened.
< BlueMatt>
i assume you ended up with 0.15.0-zesty6
< harrymm>
sounds right.
< harrymm>
not sure about that 6 but iirc it was :)
< BlueMatt>
i dont actually know how to turn that into debugsyms in gdb, but I believe dpkg -i will let you install the ddeb file
< BlueMatt>
harrymm: I think it might magic....if you download the ddeb file there, dpkg -i it (or otherwise install it like a normal package) and then re-open gdb, it may know to search usr/lib/debug
< harrymm>
double-click worked. lol. gdb is showing symbols now.
< harrymm>
but it frustratingly seems to not have the symbols dammit. it loaded them ok ...
< harrymm>
aww. should i have told gdb to load symbols from the symbols downloaded? it says it's reading them from bitcoin-qt (which doesn't have them)
< achow101>
harrymm: I believe so. I don't remember the gdb commands/params for that though
< harrymm>
i see a -s <file> but dunno what file i got
< harrymm>
i apologize for my naivety :)
< BlueMatt>
your file is /usr/lib/debug/usr/bin/bitcoind
< harrymm>
ahh
< harrymm>
wait. bitcoind or bitcoin-qt?
< BlueMatt>
oh, no, bitcoin-qt, sorry
< BlueMatt>
oh, wait, lol wrong file
< BlueMatt>
sec
< harrymm>
ok
< BlueMatt>
yea, obviously you want the -qt dbgsym ddeb instead
< cfields_>
i have a pretty long stream of stuff to prep for libevent, but i don't want to burn everyone out by nagging too much. would you all prefer a few prs, all of which build on each-other, and a final one that incorporates everything?
< sipa>
i'll work on the segwit-by-default stuff for 0.15.1
< wumpus>
added 11089
< cfields_>
(#10663 is the first of those. It's by no means high priority, other than it's necessary for the rest)
< wumpus>
cfields_: that depends; if some part stands on itself, it might make sense to PR it first then give it as a blocker
< jonasschnelli>
cfields_ I Prefer a single one to get the overall pictures
< cfields_>
wumpus: thanks
< wumpus>
but if it's a single one there's just so damn much to review
< instagibbs>
jonasschnelli, or all of them, chained, with backpointers to first one to review
< gmaxwell>
this gui crash issues should be considered a 0.15.1 blocker, but we still aren't sure of the precise cause.
< BlueMatt>
jonasschnelli: sure, but you cant merge that...opening one which will be final eventually and then breaking it into chunks is also ok
< wumpus>
gmaxwell: agree
< BlueMatt>
gmaxwell: yup :(
< cfields_>
jonasschnelli: ok, i can break them up into nice chunks, and have a tracking PR with them all rebased on top of eachother
< gmaxwell>
considering the flood of reports I am really no longer able to believe we didn't recently introduce it.
< cfields_>
i think that's pretty common these days
< wumpus>
cfields_: sounds good to me
< gmaxwell>
(maybe via a dep upgrade)
< michagogo>
o/
< jonasschnelli>
one for conceptual overview and multiple for real merge
< wumpus>
gmaxwell: agreed
< cfields_>
gmaxwell: possible that other clients are dinking with config files?
< jonasschnelli>
(sorry phone typping)
< gmaxwell>
that was a theory I had too but have seen no evidence of it.
< gmaxwell>
harrymm: have you run bitcoin unlimited or bitcoin cash or likewise on that system you crashed on?
< morcos>
Wouldn't we see 0.14 reports in that case
< wumpus>
we really need a config or regtest dump from someone that has the issue
< BlueMatt>
harrymm: how are those -qt debug symbols coming?
< wumpus>
before they run -resetguisettings
< wumpus>
in retrospect we should have made resetguisettings dump the settings to a backup file
< jonasschnelli>
cfields_ : perfect
< cfields_>
gmaxwell: iirc we didn't bump qt for 0.15. so deps seem unlikely
< achow101>
wumpus: we should start doing that now
< wumpus>
I mean you only run it when something is wrong
< wumpus>
achow101: yes
< wumpus>
#action Make -resetguisettings dump settings to troubleshooting file in datadir
< gmaxwell>
cfields_: well I'm not completely sure that the issue is 0.15.x specific based on report load it could have been, say, 0.14.2 too ... and just a lot of people are upgrading.
< sipa>
"oh, it's faster, i'll try running a full node again"
< cfields_>
gmaxwell: what's the OS diversity?
< wumpus>
but it was *never* reported for 0.14.x
< sipa>
wumpus: fair point...
< wumpus>
it would explain more reports, sure
< gmaxwell>
we have a linux report now. so far mostly windows reports.
< achow101>
gmaxwell: I suspect that's because more people use windows than linux
< gmaxwell>
I don't think we've had a mac report. maybe there are just no mac users. :P
< cfields_>
ah damn, i was thinking it could be a windows update
< sipa>
did we update qt in between 0.14.2 and 0.15.0?
< harrymm>
gmaxwell: not those you mentioned. i did try some other bitcoin python stuff at various times tho
< cfields_>
hmm. I can run on osx and plug/unplug monitors like a madman.
< gmaxwell>
harrymm: thanks.
< achow101>
cfields_: it's not a monitor problem
< gmaxwell>
So thats counter evidence to the theory that bch or bu is corrupting it.
< wumpus>
the monitor problem just disappears the window
< wumpus>
I think this is unrelated
< achow101>
This is definitely unrelated
< cfields_>
ok
< jonasschnelli>
is that still the offscreen issue?
< gmaxwell>
There may be two issues fixed with the same thing or two manifestiations of the same issue.
< harrymm>
BlueMatt: i got the right symbols down and loaded into gdb, but there's still many symbols i don't have. i was checking if the relevant ones were there but not sure i have the right skills anyway so i will pastebin what i have
< wumpus>
jonasschnelli: was that the same problem?
< * BlueMatt>
gets the impression there are at least 2 distinct issues here (+ the offscreen one which is not a segfault, right?)
< wumpus>
jonasschnelli: I don'tremember that one was fixed by clearing gui settings
< wumpus>
the offscreen issue is not a segfault, ever
< jonasschnelli>
no... not possible IMO
< jonasschnelli>
11171 seems totally unrelated to the offscreen issue
< wumpus>
the refreshWallet crash was intermittent, very hard to reproduce
< * BlueMatt>
also doesnt believe this exists on 0.14.2...so far 2 reports from ppa folks, and they tend to be a rather well-upgraded bunch
< wumpus>
this one is 100% reproducible
< wumpus>
unless you clear the settings
< jonasschnelli>
Okay. I'll track down 11171
< BlueMatt>
harrymm: yea, pastebin what you have would be great
< achow101>
jonasschnelli: that's what we're doing now with harrymm :)
< jonasschnelli>
xyzzy099 == harrymm?
< gmaxwell>
BlueMatt: offscreen gets the same report from users though: window doesn't appear, resetting the gui settings fixes it.
< jonasschnelli>
gmaxwell: I have tracked this down and it's no longer present in 0.15
< achow101>
jonasschnelli: no, different people, same symptoms, possibly same problem
< jonasschnelli>
(official builds)
< jonasschnelli>
It may happen if you self compile with <Qt5.6
< achow101>
(symptoms being crash after splash screen)
< wumpus>
yes the offscreen one has unclear status on the release binaries, jonasschnelli's testing points at it being fixed
< BlueMatt>
jonasschnelli: which issue is that?
< BlueMatt>
ah, offscreen
< achow101>
wumpus: I believe the offscreen issue should be fixed in 0.15
< wumpus>
achow101: yes
< BlueMatt>
it'd be nice to fix the qt5 issues so that ppa can upgrade to it instead of being stuck on qt4......
< jonasschnelli>
It's fixed in 0.15.0 (I have tested with Win7,8.1/10)
< wumpus>
BlueMatt: just wait for unity to die
< gmaxwell>
jonasschnelli: how does <Qt5.6 come into it?
< wumpus>
wasn't the most serious qt5 problem on ubuntu the tray icon thing? no such issue on GNOME
< jonasschnelli>
gmaxwell: I'm not sure if Qt is related. I could not find if the bug was fixed upstream (I think we had a Qt depdendency upgrade from 0.14 to 0.15) or if its fixed in out sources.
< BlueMatt>
wumpus: heh, I mean there was discussion of killing the tray icon
< BlueMatt>
wumpus: yes, I believe the tray icon was ~the only blocker
< gmaxwell>
jonasschnelli: the problem is that we've had users reporting all through the rcs something that sounds like that, and now in releases. So just saying its fixed isn't helpful, since there is clearly something that isn't fixed.
< wumpus>
anyhow that's yet another different issue
< BlueMatt>
wumpus: there was some minimize issue that was also there, but I believe it was related...just kill the tray icon and its fixed, I think
< achow101>
gmaxwell: jonasschnelli: I think you're talking about different issues
< jonasschnelli>
gmaxwell: IMO its an upstream bug.
< jonasschnelli>
gmaxwell: I need to track it down. I just tested 0.14.1 and 0.15.0 on win7,8.1,10 and verfied that it is fixed in 0.15
< BlueMatt>
ok, but lets be clear there are multiple bugs here
< achow101>
BlueMatt: yay!
< jonasschnelli>
sipa: sorry,... we slipped to the offscreen issue.
< sipa>
okay, ignore me
< BlueMatt>
the offscreen issue, which jonasschnelli believes to be fixed
< gmaxwell>
jonasschnelli: what does verified that it's fixed in 0.15 mean? Does that just mean you were unable to reproduce it at all?
< BlueMatt>
also the settings issue, which is L131 as above based on harrymm's backtrace
< wumpus>
gmaxwell: yes, that means it
< jonasschnelli>
gmaxwell: I set the window position by RegEdit to 3000,3000, 0.14 has the issue, 0.15 doens't
< achow101>
BlueMatt: I don't see how there's a bug there
< wumpus>
jonasschnelli: thanks for doing a sane, reproducible test :)
< jonasschnelli>
11171 is far more important
< gmaxwell>
jonasschnelli: okay, but if the issue users are hitting is that the use positions the window in the bottom left of the screen (below task bar) then they'd still be hitting it... since the reproduction was synthetic.
< wumpus>
I agree
< wumpus>
crash bugs are more important, and this happens for a lot more users
< gmaxwell>
I know that at least one of the users I helped during the RCs wasn't crashing (Because they had to kill bitcoin-qt in their task manager)
< jtimon>
oops, I'm late
< jonasschnelli>
gmaxwell: I can investigate again and report
< jtimon>
yay 0.15!
< sipa>
gmaxwell: sure, but there's only so much we can do
< gmaxwell>
sipa: we could stop saving the position.
< wumpus>
yes, ideally we should test all 8 areas outside the screen, something for an automated test
< wumpus>
or just nuke the remember-position functionality
< jonasschnelli>
my observation is that Qt handles offscreen situation pretty well... if a certain area of the window is offscreen, it re-centers.
< wumpus>
the longer this remains an issue the more I'm tempted to the latter
< sipa>
does -resetguisettings change anything but the remembered window coordinates?
< gmaxwell>
jonasschnelli: QT5 but perhaps not QT4? (which, for example, the ppa uses, I believe)
< wumpus>
sipa: yes, it clears all settings set through the gui optioins dialog
< jonasschnelli>
It may kill your dbcache / proxy settings
< sipa>
oh!
< jonasschnelli>
Oh. PPA / QT4
< achow101>
Oh, I think I found harrymm's bug
< jonasschnelli>
Yes. The issue is very likely present there...
< wumpus>
as well as all other things the GUI remembers (there might be something in the send dialog with fee, I vaguely remember)
< gmaxwell>
sipa: you missed earlier discussion, based on debuglog traffic achow has suggested its actually the proxy that is implicated in the crash.,
< jonasschnelli>
I don't see a reason to do the PPA with Qt4?
< BlueMatt>
achow101: yea, there's only one button in that group
< gmaxwell>
sipa: I pointed out that 0.15 did change proxy handling (name lookup) but a cause of a crash isn't obvious there.
< sipa>
gmaxwell: ah
< achow101>
BlueMatt: I mean how different settings for nCustomFeeRadio cause a segfault
< jonasschnelli>
Maybe we just add a failsafe: if offscreen then re-center... (but sounds simpler then it is)
< gmaxwell>
the user in here with the crash on linux knows the function where the segfault happens for him (inside a qt button setting function)
< wumpus>
achow101: interesting, so it might be the custom fee setting?
< BlueMatt>
achow101: yes
< wumpus>
achow101: I forgot about that one completely as it's not in the options dialog
< BlueMatt>
wumpus: it appears to be a what-button-had-you-clicked-on-in-14.2 issue
< achow101>
wumpus: yes
< achow101>
I set nCustomFeeRadio=1 and that causes a segfault
< gmaxwell>
oh we also changed the options for fees at some point in recent memory, could people have settings that made sense in 0.14 but not now?
< sipa>
if there's nothing else; i have some open questions about segwit-by-default support in 0.15.1
< wumpus>
#topic segwit-by-default support in 0.15.1
< BlueMatt>
oh, wait, hmm
< sipa>
my idea was to have a cmdline option to select a default address style, which could be p2pkh, p2sh-p2wpkh, or p2wpkh
< BlueMatt>
or jonasschnelli can do it
< sipa>
(where the middle one is default)
< sipa>
and have an optional argument to getnewaddress to override it
< BlueMatt>
sipa: seems reasonable?
< sipa>
open question: separate option for change?
< instagibbs>
imo yes
< BlueMatt>
imo yes
< achow101>
sipa: yes
< sipa>
open question: do we want to return both p2wpkh and p2sh-p2wpkh (for now), as there is an efficiency gain when you want to give both to a peer
< sipa>
downside: may not want we want to support longer term with split chains
< achow101>
no, I think that will confuse people
< sipa>
upside: more efficient to rescan
< instagibbs>
I'd say no
< jonasschnelli>
may confuse
< instagibbs>
users who care will crank the option surely
< gmaxwell>
we can't do that by default, interface breaking change. If you want to call getnewaddress with style=gangnam and it returns both, that would be fine.
< achow101>
style=gangnam <-- lol
< morcos>
yep, i tested, running 0.14, setting the at least button, 0.15 crashes
< sipa>
but style=gangnam would be pre-deprecated, and scheduled for removal in a future version
< morcos>
oops was backlogged
< achow101>
morcos: good to know that
< wumpus>
hahahahaa
< BlueMatt>
achow101: morcos also tested the 6ba2...fix from above, which fixed it, though the real fix isnt something that stupidly hacky
< sipa>
ok, end of my topic
< cfields_>
let's just let users decide with a 1-option combo-box :p
< gmaxwell>
I'd say we could make the GUI show both too, except the URI/qr code can't really do that.
< cfields_>
er, radio
< sipa>
cfields_: unary encoding, i like it
< morcos>
wait, i'm confused
< morcos>
are you serious about giving both addresses
< morcos>
no, why would we do that
< BlueMatt>
lets not do that
< BlueMatt>
you could also just call getnewaddress twice
< BlueMatt>
who cares
< gmaxwell>
morcos: as an option. The reason is so you can say "here is the bech32 one if you can pay to it, otherwise use X"
< morcos>
you should have a way of selecting which type of address you want for change or for getnewaddress
< morcos>
then give them 2 different keys
< morcos>
that's how it'll work in 0.16
< morcos>
lets not try to be cheap and save a couple of keys and start teaching people that you can use one or the other
< sipa>
BlueMatt: my wallet.dat barely fits on a 3.5" floppy disk anymore...
< cfields_>
morcos: +1
< instagibbs>
will there be an argument to getnewaddress to override?
< instagibbs>
id hope so
< morcos>
i agree that's a downside, but its more important to set the precedent that these thigns are NOT interoperable
< morcos>
yes
< sipa>
instagibbs: i hope so, yes
< instagibbs>
ok, then that's fine
< gmaxwell>
okay... when I talked to sipa about it my objection was that we couldn't support it in the future. his counter was that we don't have to offer it in the future.
< instagibbs>
i prefer
< BlueMatt>
somehow I doubt bdb is useable on floppy-latency disks anyway :p
< gmaxwell>
instagibbs: yes, there would be an option, setting would just set the default.
< instagibbs>
then I see no reason to return both
< wumpus>
yes,we need to make it very clear they're not interoperable, that you can't, in general just convert the one to the othe and have it work
< BlueMatt>
then require two getnewaddress calls
< sipa>
sounds good, you need to call getnewaddress twice
< sipa>
ack
< achow101>
+1
< sipa>
no gangnam
< morcos>
also in the scheme of things, each 0.15.1 wallet is wasting 2000 + N * (# getnewaddress calls) + (# changes) keys.... where N is 2 if you do what I want (only in the cases where you give out both) or 1 if you do what you want
< morcos>
it makes no difference relatively speaking for almost all users
< jtimon>
wumpus: ack on removing remember position functionality until we can test it automatically
< gmaxwell>
jtimon has the gribble disease.
< wumpus>
jtimon: that'd make sense, I guess
< gmaxwell>
(20 minutes behind. :) )
< wumpus>
seems the segwit-by-default topic is conclded, anything else?
< gmaxwell>
I think we need to announce a workaround for this issue we all collectively figured out through our joint effort where no one person did all the work during the meeting.
< wumpus>
haha yes gribble's behavior seemed very curious and random, before I realized it was just backlogged (or rather, github was?)
< BlueMatt>
yes, do we have a mechanism for release errata?
< wumpus>
or make a 0.15.0.1
< BlueMatt>
given the ppa is still not up (cause arm qt...) I'll probably ship that with the hacky workaround patch posted above
< BlueMatt>
unless there are objections
< wumpus>
did you manage to debug the ARM qt issue? I'm curious
< wumpus>
no objections, if you can patch it in your distro, do so
< wumpus>
it's zero risk...
< BlueMatt>
there appear to now be at least two separate issues, a miscompile, and I now have a stacktrace for another test_bitcoin-qt fail that I'm looking at now
< achow101>
BlueMatt: I believe (not tested yet) that you can just remove L131 entirely
< sipa>
let's fix the things at least in the 0.15 branch
< gmaxwell>
I won't ack 0.15.0.1 because I do none of the required work for it but it might be nice.
< sipa>
then depending on progress we can see whether it goes in 0.15.1, or if a 0.15.0.1 may be needed (at release manager's discretion...)
< wumpus>
achow101: possibly, but BlueMatt's fix is obviosuly correct, a better fix is to just remove the setting completely
< BlueMatt>
achow101: well the commit linked above works, so whatever
< wumpus>
achow101: and the single-choice radio button
< gmaxwell>
what sipa said
< wumpus>
but for a quick hack that change is good
< morcos>
in master can we please fix properly, remove the whole group
< wumpus>
yes
< sipa>
yes
< achow101>
yes
< gmaxwell>
yes
< gmaxwell>
someone will need to contemplate how to prevent this kind of issue in the future.
< wumpus>
well yes let's fix it on the branch then decide whether to do 0.15.0.1
< wumpus>
better testing of the gui is the only answer
< achow101>
gmaxwell: fuzz the qsettings options :)
< instagibbs>
remove all features until qt is a single button
< jonasschnelli>
Better GUI tests... but more important, "upgrade tests"
< gmaxwell>
"moon"
< wumpus>
hah
< jonasschnelli>
Non of our test do cover upgrade of wallets, etc.
< gmaxwell>
(responding to instagibbs)
< instagibbs>
jonasschnelli, hmm good point
< jonasschnelli>
Upgrade tests would probably require static data files from older versions....
< wumpus>
well at least the reduced one radio buttons group to one button, that's a start...
< morcos>
was fuzz qsettings a joke? i did that with the fee estimation changes manually, i think thats a good idea
< wumpus>
s/the/we/
< achow101>
morcos: not really
< wumpus>
no, it's not a joke, it'd help with robustness against corrupt configs a lot
< morcos>
ok, the smiley threw me
< wumpus>
but as we're not even fuzzing bitcoin.conf settings yet
< achow101>
but it would mean a lot more changes since weird shit in qsettings totally screws up qt
< morcos>
ha ha, fuzzing bitcoin.conf DEFINITELY breaks things
< achow101>
we would need better bad-setting rejection
< wumpus>
gui testing is always at least 3 times as much work
< jtimon>
sipa: yeah, both formats seems like un ugly optimization. Doesn't look like it's worth it
< gmaxwell>
sipa: I think he's still 20min behind.
< jonasschnelli>
Not sure if fuzzing qt-settings (QSettings) make sense. It's not a file edited by users
< morcos>
is jtimon working on-site on the blockstream Mars project
< BlueMatt>
jtimon: is stuck on moon
< jtimon>
gmaxwell: well, I arrived 30 mins late
< jonasschnelli>
Fuzzing peers.dat or similar would also make little sense I guess
< wumpus>
jonasschnelli: but it can get corrupt, like anything
< wumpus>
though I agree there's a limit
< instagibbs>
that would at least test it handles corrupted files right
< instagibbs>
recently ran into a case where we werent
< jonasschnelli>
Corrupt files should be handled by Qt IMO
< morcos>
usually with bitcoin.conf we don't change the meaning of the options (cough cough sipa)
< jonasschnelli>
The file itself is hidden on our application layer
< jonasschnelli>
We just deal with QSettings
< morcos>
we could be better about making sure we rename options in QT if we are goign to change their meaning
< wumpus>
yes
< wumpus>
much, much better to lose the setting than crash
< jonasschnelli>
morcos: yes!
< wumpus>
unless it's soomething like the proxy
< wumpus>
but a nicety like remembering the fee setting? nah
< jtimon>
0.15.0.1 ? why not 15.0.1 directly and we stop writing the 0. prefix now? /me hides
< jonasschnelli>
I don't understand why the crash does not happen on OSX (could only reproduce on Linux)
< wumpus>
likely the implementation of radio button group is different there
< wumpus>
making it return e.g. a dummy object instead of corruption or null when reading out of range
< wumpus>
macosx users just got lucky
< sipa>
wumpus: we have occasionally had x.x.x.1 released for bugfixes that affect just some platforms
< sipa>
*releases
< instagibbs>
2 minutes
< morcos>
one could argue they were silently forced to lose their at least setting which made them erroneously pay the wrong fees
< wumpus>
sipa: yes, I wouldn't like to burn 0.15.1 on this mainly
< sipa>
wumpus: agreed
< jtimon>
finally catched up...to late to suggest a topic, but perhaps we can talk about it after the meeting
< jtimon>
is about an index for scriptPubKeys
< wumpus>
yes, we're done for today
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Sep 14 19:59:45 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< jtimon>
well, my thought was give an option -deletespent or something of the short, if you start using the index, it starts with an utxo at a given height, if you select the option, it conserves spent outputs but won't go to the past: if you want it full you need to reorg
< jonasschnelli>
calling setChecked() on a nullptr won't crash OSX but does segfault (correctly) on linux
< BlueMatt>
jonasschnelli: uhhhhhhh
< BlueMatt>
I hope not?
< jtimon>
but perhaps that's not acceptable either, anyway, thanks wumpus sipa that's useful to know
< jonasschnelli>
Yeah.. seems strage... maybe a local issue.. it should crash
< wumpus>
does it really return null when out of range though on osx?
< wumpus>
or some softly padded dummy object
< cfields_>
jonasschnelli: huh, i just saw something related to that in a recent qt changelog
< jonasschnelli>
cfields_: thanks... will check later (on the run)
< bitcoin-git>
[bitcoin] jonasschnelli opened pull request #11332: Fix possible crash with invalid nCustomFeeRadio in QSettings (master...2017/09/qsettings_1) https://github.com/bitcoin/bitcoin/pull/11332
< BlueMatt>
jonasschnelli: I really dont think thats the right fix...groupCustomFee literally only contains one button now
< BlueMatt>
jonasschnelli: better to just literally remove groupCustomFee and the button wholesale
< BlueMatt>
as well as delete the nCustomFeeRadio setting
< gmaxwell>
there are a half dozen places in the code where we ->button()->foo
< meshcollider>
Or at least probably a separate issue to 9683 and 9883
< achow101>
Meshcollder: I think you are talking about 11262
< achow101>
Not 11171
< luke-jr>
setSortingEnabled is a distraction: the crash is "free(): invalid next size (fast)" which indicates corrupt memory before it got there
< luke-jr>
it could very well be 11332-related
< luke-jr>
the only way to confirm is valgrind
< luke-jr>
(on an affected system)
< jnewbery>
jonasschnelli: (slightly delayed) you can also `get commit -C <hash>` if you want to retain the entire commit message including author - and there's no risk of mistyping the author's name
< jnewbery>
s/get/git
< * luke-jr>
learns uppercase -C skips the editor.
< achow101>
Git has a lot of fun options that most people don't know about
< luke-jr>
I'm probably the only one in the world who uses git write-tree <.<
< achow101>
What's that?
< luke-jr>
git-write-tree - Create a tree object from the current index
< luke-jr>
typically followed by git commit-tree
< luke-jr>
in my case, I do this sequence to produce commits with more than 2 parents
< ShaunR>
Has anybody ever proposed making bitcoind's blocknotify and walletnotify options support a URL? So you could set -blocknotify="https://domain.com/bitcoind/notify/block.php" and have it POST %s? I'm thinking about attempting to write that functionallity into bitcoind but unsure if anyone else would find it useful or if the devs would even consider adding it.
< luke-jr>
probably a trivial way to make it POST too
< ShaunR>
luke-jr: thats true, you could do something like that i guess.
< ShaunR>
I was thinking about making it a bit more elaborate, like if the POST failed to queue the notification or something.
< luke-jr>
could make blocknotify retry if the exit code is non-zero?
< ShaunR>
but your solution may be the simplist right now.
< luke-jr>
but tbh, retry logic could be outside too
< ShaunR>
I wanted to avoid the requirement of a outside script/binary too
< esotericnonsense>
yes, you could create an external script that queues notifications to do stuff with
< luke-jr>
ShaunR: avoiding that requirement, is not a design goal IMO
< esotericnonsense>
it'd probably be easier to use the zmq notification for that, just listen on it, add new entries to a queue, periodically try and flush the queue into this post mechanism
< luke-jr>
ShaunR: better to run as little code in the security-critical process as possible
< esotericnonsense>
indeed, it's not really bitcoind's responsibility
< luke-jr>
esotericnonsense: ZMQ is good at losing notifications
< esotericnonsense>
luke-jr: using IPC? tcp over seperate machines, perhaps
< esotericnonsense>
regardless of whether you use zmq or not it's similarly easy though :)
< achow101>
harrymm: do you have a debug.log file from the time of the crash?
< esotericnonsense>
from #bitcoin: dingus | TYPO at the very top of https://bitcoin.org/en/release/v0.15.0 "14 October 2017" <- It's not October, yet, I hope
< bitcoin-git>
[bitcoin] danra opened pull request #11333: Use `std::nth_element` instead of `std::sort` to calculate median time past (master...improve/median-time-past) https://github.com/bitcoin/bitcoin/pull/11333
< tloriato>
Hello! I was looking for how I could import a BIP32 Extended Key into the Bitcoin Core wallet? I've tried the RPC Documentation but got no luck there.
< sipa>
you can't
< tloriato>
So I have to derive each desired path using another lib and import it with WIF?
< sipa>
for now, yes
< tloriato>
thank you, sipa
< tloriato>
oh, one more thing, sorry! bitcoin core uses m/0'/0'/k' for derivation path
< tloriato>
is there a way I could request a new address from an arbitrary path from the rpc?
< tloriato>
or at least associate one i ( m/0'/i'/k' ) for one account?
< sipa>
no, new addresses come from the keypool, which is preloaded with keys from one chain
< sipa>
in 0.15, there are two chains (one for normal addresses, one for change)
< sipa>
and no, you can't configure the path - especially not for accounts, which are deprecated
< tloriato>
Well, I think I have the information that I need now.
< tloriato>
Thanks sipa, it was really helpful
< sipa>
yw
< tloriato>
sipa in which cases does the bitcoin wallet changes the i from the path?