< provoostenator>
Happy Monday! Getting a Segmentation fault: 11 on macOS master when opening wallets. With and without --enable-debug.
< gmaxwell>
run inside a debugger and find out where its crashing?
< provoostenator>
Will try
< fanquake>
provoostenator calling the loadwallet rpc, through the gui?
< provoostenator>
fanquake: bitcoind crashes when starting if a wallet is configured. I can start with -nowallet, and it crashes as I load through RPC call or create a wallet.
< fanquake>
provoostenator from a quick look, I'm not seeing a crash like that. built master, -nowallet, created new wallets and loaded existing.
< provoostenator>
My guess is that it will go away as soon as I update homebrew or something like that, so I'll try to get a trace first.
< provoostenator>
"breakpoint set --name _exit" doesn't catch this in lldb, any suggestions?
< provoostenator>
(I'll try gdb as well)
< wumpus>
doesn't it always trap on segmentation faults?
< provoostenator>
I thought so as well. lldb says "error: process exited with status -1 (Error 1)", so maybe that's something else...
< wumpus>
I mean, what are you trying to do by trapping _exit ?
< wumpus>
and you can't do 'bt' after that?
< wumpus>
to me it sounds like your debugger isn't working at all
< wumpus>
it ignores the trap, runs the trap handler and lets the process exit
< wumpus>
in gdb at least you can set the signals it should break on with 'signal', but, SIGSEGV is always that by default, it shoudln't be necessary
< provoostenator>
Indeed, "lldb src/bitcoind -- -nowallet" also does an exit 1, so I'm using the debugger wrong.
< provoostenator>
-1
< provoostenator>
aaargh, it was trying to pupop a permission window on my desktop, that's what failed.
< provoostenator>
This might be a borked bdb@4 homebrew thing
< fanquake>
provoostenator make sure you keep a copy of that "A" wallet
< fanquake>
wumpus Hope you are doing well. 15809, 15794, 15790, and maybe 15756 are mergable
< wumpus>
provoostenator: it might be; it happens in the bowels of berkeleydb, which means either it's being passed garbage arguments, or there's something like an ABI conflict
< provoostenator>
It crashes with "createwallet" too, added to the gist...
< wumpus>
(the former is not possible to diagnose from this as, as usual with c++ and debugging, the argument data has been optimized out)
< provoostenator>
I'll try a depends build as well as --with-incompatible-bdb.
< wumpus>
provoostenator: thanks for investigating - adding upstream label
< provoostenator>
When Sqlite? :-)
< wumpus>
with upstream I mean homebrew in this case, not bdb
< wumpus>
I'm sure it's possible to get the same kind of crashes when mishandling compilation/linking using any database — though that's not an argument *against* using sqlite ofc
< bitcoin-git>
bitcoin/master b4338c1 John Newbery: [rpc] Remove the addresses field from the getaddressinfo return object
< bitcoin-git>
bitcoin/master 2a854a1 MarcoFalke: Merge #15750: [rpc] Remove the addresses field from the getaddressinfo ret...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #15750: [rpc] Remove the addresses field from the getaddressinfo return object (master...2019_04_remove_address_from_getaddressinfo) https://github.com/bitcoin/bitcoin/pull/15750
< bitcoin-git>
bitcoin/master 666696b MarcoFalke: test: Have segwit always active in (Basic)TestingSetup
< bitcoin-git>
bitcoin/master fa8685d MarcoFalke: test: Use test_bitcoin setup in bench, Add test utils
< bitcoin-git>
bitcoin/master fa82190 MarcoFalke: scripted-diff: Rename test_bitcoin to test/setup_common
< provoostenator>
I'm having difficulty making ./configure forget about CPPFLAGS -I/usr/local/Cellar/berkeley-db@4 when I uninstall it.
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #15788: test: Unify testing setups for fuzz, bench, and unit tests (master...1904-testUnify) https://github.com/bitcoin/bitcoin/pull/15788
< provoostenator>
Though maybe that's just hard coded.
< gwillen>
provoostenator: in situations like this, I go straight for "git clean -dfx", but beware thats it nukes everything that differentiates your local git client from a fresh checkout, including ignored files and any changes you have not checked in
< gwillen>
it is the maximumally-aggressive "make distclean"
< provoostenator>
gwillen: I'll keep it in mind, but for now it's compiling and working despite this.
< dongcarl>
wumpus, gmaxwell: The one-shot pseudo-name resolution you guys mentioned last week for people behind Tor thru the name proxy is done using "getaddr" to seed nodes, correct?
< sipa>
dongcarl: yes, connect to seed nodes (rather than just resolve them), send getaddr, and disconnect after a response comes
< dongcarl>
Understood
< dongcarl>
It would seem that in SOCKS5 you can have UDP-over-SOCKS, which means we should be able to just use the Tor SOCKS5 proxy to do name resolution instead of the one-shot "getaddr," am I missing something?
< sipa>
dongcarl: i'm not sure we want a DNS resolver implemented inside core...
< sipa>
but yes, in theory that would work
< luke-jr>
huh? getaddr isn't DNS, nor is DNS a substitute for that step
< luke-jr>
and doesn't Tor have a resolve command?
< dongcarl>
I feel like I'm missing something important.
< sipa>
luke-jr: if you have a public connection to the internet, we gather seed IPs by just resolving the seed DNS name
< sipa>
luke-jr: if you don't, we instead connect to the DNS seed name, and request getaddr from it
< dongcarl>
sipa: So doesn't that mean we already have a resolver in core?
< sipa>
dongcarl: no, we use the OS resolver
< sipa>
but you can't use that over tor
< luke-jr>
sipa: why can't we just use the Tor resolver?
< sipa>
luke-jr: afaik it has none
< sipa>
you can only connect to a name, not resolve a name
< sipa>
(unless there is a way to resolve over socks5 i'm not aware of)
< luke-jr>
I thought Tor had a SOCKS5 extension for it
< sipa>
ah, that's possible
< luke-jr>
As an extension to SOCKS4A and SOCKS5, Tor implements a new command value,
< luke-jr>
"RESOLVE" [F0]. When Tor receives a "RESOLVE" SOCKS command, it initiates
< luke-jr>
a remote lookup of the hostname provided as the target address in the SOCKS
< luke-jr>
request. The reply is either an error (if the address couldn't be
< luke-jr>
resolved) or a success response. In the case of success, the address is
< luke-jr>
stored in the portion of the SOCKS response reserved for remote IP address.
< sipa>
seems like we should implement support for that then
< dongcarl>
luke-jr: I have a sneaking suspicion that it'll only return a single address
< gmaxwell>
dongcarl: udp over socks5 is AFAIK mostly unimplemented. (e.g. ssh doesn't implement it)
< gmaxwell>
Tor, however, implements some extensions, including a dns resolution one that could be used by us.
< sipa>
if it only resolves a single IP, we're better off using the oneshot technique, though
< dongcarl>
gmaxwell: I see, that makes sense.
< dongcarl>
sipa: Yea, I agree
< * dongcarl>
is thankful for context to include in documentation
< luke-jr>
sipa: we're supposed to only be doing getaddr to the seed-provided addresses anyway, though?
< sipa>
luke-jr: when we use the public resolving, the IP addresses the seed name resolves to are added directly into addrman
< dongcarl>
luke-jr: Do you have a Tor SOCKS5 you can try a "RESOLVE" with and see if it returns multiple entries?
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #15821: doc: Remove upgrade note in release notes from EOL versions (master...1904-docRelEOL) https://github.com/bitcoin/bitcoin/pull/15821
< sipa>
i don't think it's much of a problem to use the oneshot technique actually
< sipa>
it has advantages in being able to relay more IP addresses, and also communicate service flags and ports
< dongcarl>
sipa: True, you're right.
< sipa>
if we ever adopt v2 addr messages with NG tor addresses which aren't embeddable in IPv6 anymore, that'll even be the only option i think
< gmaxwell>
^that
< gmaxwell>
dnsseed has turned out to have a lot of issues... including stuff like the dnsseed names getting blacklisted because they return some malware ips from time to time
< dongcarl>
That makes a lot of sense. Hopefully the net_processing for `getaddr` is fast and lockless enough...
< * dongcarl>
needs to read up on dns seeds
< dongcarl>
sipa: Is there a design doc for v2 addr messages?
< luke-jr>
getaddr isn't as big a deal over Tor, but I'd be at least a little concerned if we had address-seed servers getting direct connections
< dongcarl>
perhaps a stupid idea, but I think serving getaddr requests could benefit from process separation once we move over to that being the default
< sipa>
what does process separation have to do with this?
< dongcarl>
I'm probably thinking about this the wrong way, but I'm just thinking about how to make sure the address-seed servers don't get overwhelmed, and a bug there won't allow someone to populate addrman with malicious nodes.
< gmaxwell>
sounds like magical thinking
< dongcarl>
gmaxwell: Well, I'm always open to hearing why my stupid ideas are stupid
< gmaxwell>
process seperation does a fairly limited, but useful thing-- isolates sub parts so they can crash and restart seperately and primarily puts code into seperate memory spaces so that bugs that cause information leaks don't see other codes data. None of that is implicated for getaddr. If getaddr's logic is broken, it'll be broken regardless. Getaddr is also exceptionally trivial.
< gmaxwell>
So it isn't like its more likely to have problems worse than any other network message.
< dongcarl>
gmaxwell: Thanks for explaining, that makes sense!