Version 0.10 segfaults on OS X 10.6.8 #5797
Comments
|
Thanks for reporting! 10.6 is supported for this release (though deprecated and officially dropped for 0.11). The user-base is small though, so it's possible that it went untested through the rc series. Does bitcoind have the same issues? You can grab it from here: https://bitcoin.org/bin/0.10.0/bitcoin-0.10.0-osx64.tar.gz . That would be a good thing to know as a starting point for tracking down the problem. It would also be helpful to run the tests from that tarball. For more helpful debugging, here's an unstripped 0.10 bitcon-qt built with extra debugging enabled. The usual disclaimer applies: please assume that I'm trying to trick you into stealing your coins by having you run this binary (I'm not though :). If you understand and would still like to help, grab the binary here: https://bitcoincore.org/cfields/bitcoin-0.10.0/bitcoin-0.10-osx-debug If that still crashes, the output should be much more helpful. |
|
Thanks for the reply. It turns out that bitcoind segfaults, too, so it's not a GUI bug. Here's the full debug output: So it crashes as it tries to make the first peering connection. Note that I'm on an IPv6 network. I'm running the debugging version of Bitcoin-Qt you linked right now. I'll report back with those results; will the debugging output be sent to the default debug.log file? (I also have some debugging output in there from my earlier runs of Bitcoin-Qt v0.10, it seems.) |
|
The debugging version of Bitcoin-Qt also segfaulted. Here's the output from debug.log: And that's it. (If there's any extra debugging output somewhere, I didn't see it.) The OS's crash report is substantially the same as the one I posted previously, showing the segfault happening in bitcoin-msghand in Thread 11. Here's the debugging output from a run of the standard version of Bitcoin-Qt v0.10: Anything else I can run? |
|
Run and post the resulting output. |
What am I doing wrong? |
|
By the way: And: |
|
Could you please post the osx crashlog from the debug version, even if you think it looks the same? The symbols are missing from your original (most look like non-virtual thunk to boost::exception_detail...+xyz). The debug version should have the real symbols. |
|
Use e.g. |
|
Here's the crash report from the debug version: |
|
Out of curiosity: does it crash when you are not connected to the Internet (pull the plug ;-). |
|
Here's the GDB output: |
|
That's not a crashlog from the debug version (it shows the path as: /Users/username/Downloads/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt). Please run the debug version again for a crash, and double-check that the crashlog shows the correct path. |
|
No, it's not! Sorry, I have so many versions of Bitcoin Core around now that I confused myself. Running now. ... |
|
OK, here's the REAL output from the debug version: And here's the crash report: |
|
Per Pavel's suggestion, I tried running without a network connection. No segfault. Then it crashes as soon as I plug back in. |
|
Hmm, it looks like bool ProcessMessages(CNode* pfrom)
{gets called with |
|
Net: without network, no messages to handle, so no crash. Thanks for test. |
|
You want the gdb output for the debug version of Bitcoin-Qt? Running now. ... |
|
|
Hmm, std::string CMessageHeader::GetCommand() const
{
return std::string(pchCommand, pchCommand + strnlen(pchCommand, COMMAND_SIZE));
}10.6.8 and |
|
10.6.8 doesn't have |
|
it exists at build-time but not at run-time. We need to expand on this check. |
|
@theuni Looks like we need to add a workaround to the gitian builds to guess if |
|
@ericpashman I suggest to compile from source, if you are able to. |
|
I can do that if you to want to distribute a working binary or something, but for my own purposes I will probably just fall back to v0.9.3. I'm only running this node because I have a spare machine sitting around doing nothing. ... |
|
@paveljanik Please don't suggest that. This is a crasher on a supported OS. As long as we have someone jumping through hoops to help, let's keep providing hoops! @ericpashman New test-build coming up in just a few min. |
|
@ericpashman Please give this a try: https://bitcoincore.org/cfields/bitcoin-0.10.0/bitcoind-strncpyfix Since bitcoind was crashing on you the same way, I built that instead of -qt for the sake of simplicity in testing. It contains this quick hack-job: theuni@e0574c3 |
|
Running now. By the way, has anybody publicized the fact that bitcoind and the other Unix executables are now available pre-built for OS X? It looks like that's new for v0.10, and I don't think many people know about it. It would be nice to get bitcoind available on Homebrew, etc. |
|
It works. |
|
Thanks for testing, Eric! |
|
No prob, thanks to you and Cory for the bug-quashing! |
|
@laanwj As @paveljanik suggested on IRC, theuni@e0574c3 is a nasty hack that's overly complex. Master has already dropped 10.6 as a supported platform, so there's no need for a fix there. For 0.10, would you prefer instead to simply revert the strnlen change in 62e5f8f ? I suppose a third possibility would be to just use our strnlen_int() implementation unconditionally. |
|
@ericpashman as to your previous question, having pre-packaged binaries available via homebrew is an interesting idea. @fanquake @DomT4 might there be some interest in bundling the official util programs (bitcoin-cli, bitcoin-tx, as built by gitian) as binaries for homebrew? bitcoind is probably less interesting since it needs app-nap installed, though maybe there's a way to do that without packing it into an .app ? Just thinking out-loud, I'm not sure if they'd actually prove useful by themselves or not. |
|
Homebrew seems to be reluctant to add any bitcoin formula, see the comments in #29538 and #28914. However there is a bitcoin tap that contains formulas for various bitcoin software and is the suggested go-to by the homebrew team. bitcoin-tx/cli should probably be added there. |
|
@fanquake I'm suggesting that the formula install pre-built binaries from bitcoin.org, rather than trying to build from source. I assumed that would change the outlook a bit from the homebrew side. |
|
I'm confused by the Homebrew maintainers' comments in rejecting past pull requests that would have added a formula for I do think having @theuni, can you clarify what the issue is with App Nap and |
The core Homebrew/Homebrew repo doesn't use binaries as a rule. Part of that is because it's important to offer people from source builds (And I guess historically that's what people expected from MacPorts/Homebrew/Fink), and part of that is because Homebrew creates its own binaries (Bottles, as you know them) from the source code compile. There are certain exceptions, but the maintainers have vocalised a desire in the past to minimise those exceptions. There's the Homebrew-binary tap for Binaries, and Homebrew-cask have typically been open to shipping precompiled binaries as well - The latter already ships the Bitcoin qt client. Basically, as I understand it, Homebrew/Homebrew's reluctance to carry cryptocurrency software has less to do with political views and more to do with the maintainers there pretty strongly feeling the Bitcoin community has a much vaster understanding of the software involved and would be able to better respond to any issues raised. That's just my understanding though, I don't speak for the maintainers at Homebrew/Homebrew.
I have both Bitcoin, with or without GUI, and Electrum with GUI available in my crypto tap as well, alongside a whole host of other unrelated formulae, the descriptions of which you can see here if curious. My Bitcoin formula doesn't have a bottle available per prior discussions/requests with the Bitcoin team here, but you can build it from source fine. I keep it updated and such. I'm not completely opposed to carrying the binary util programs there if there's desire - The benefit of running a tap is more flexibility to flout the normal rules 😸. |
|
@ericpashman As much as possible, we don't want distros building and packaging their own bitcoin binaries, because they tend to ignore our warnings about consensus-critical issues. For example, they usually to want to use their own versions of leveldb and berkeley-db. We spend a lot of time vetting toolchains and dependencies to avoid such issues. We also spend a lot of time on a deterministic build process so that users can verify that the binaries have not been tampered with. For that reason, I've suggested here that homebrew could bundle those binaries for ease-of-use for homebrew users. As for App Nap, it is disabled by adding a key (LSAppNapIsDisabled) to our Info.plist, which is shipped in our app bundle. If you just run ./bitcoind or ./bitcoin-qt, you'll notice that App Nap will kick in, slowing things down greatly. See here: #5041 |
|
@DomT4 great answer, thanks. |
|
Same crach on my 10.6.8 MacMini. Will there be a 0.10.1 GUI version working on MacOSX 10.6 soon ? |
|
Solved by #5926 on 0.10 branch. Not applicable on master, as 10.6 support has been dropped. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I've been running a Bitcoin node on an old MacBook (Core 2 Duo, OS X 10.6.8). After updating to the latest release, I repeatedly see segfaults after Bitcoin-Qt.app loads completely. The app successfully verifies all blocks, then crashes shortly after displaying the full GUI.
Is OS X 10.6 officially unsupported? If not, and if anybody wants to try to track this down, I'm happy to provide testing.
Here's a full core dump:
The text was updated successfully, but these errors were encountered: