After the splash screen, it appears the main windows, but thoroughly empty. rpc works fine if started with -server=1, but you can't stop the program. debug.log looks fine, rpc order to stop gets there, but is ignored.
Environment is a minimal debian wheezy i386 vm with fluxbox, and without network.
bitcoin-qt 0.8.1 works fine there, and both versions of bitcoind too.
"thoroughly empty" means what? Can you show a screenshot?
Is that with an empty datadir or a filled one? What does an RPC stop command do?
Perhaps you can upload your debug.log, so we can take a look.
Screenshot: https://docs.google.com/file/d/0B_fyMTbLGLc3T3FiWDZDWUxrek0/edit?usp=sharing
It's a filled directory, but with neither blockchain nor keypool. The wallet has only 1 address. I could upload a debug.log, but there's nothing interesting there... The rpc stop command is received on the server side, registered on debug.log, but ignored. You can only stop it by kill -9
I'll try to debug this further, but might not be a stopper because the use case isn't very common, and because testing on real hardware seems to work fine... but it would be nice to found the cause anyway...
What does "It's a filled directory" mean?
It's not clear to me what you believe you're doing special and uncommon here is.
-keypool=0 and -connect=127.0.0.1 perhaps I'll try these and see what happens :).
Edit: Nothing, loads just fine...
Looks like #2501 is responsible for this.
@rdponticelli How did you determine this?
By bisecting. Now I'm about to test v0.8.2rc1 with that commit reverted, just to be sure.
Thanks!!
Confirmed. v0.8.2rc1 with 4881353efef81acc6ddbaaecd4ba89f012b3e87e reverted works as expected.
Just a wild guess: Can you try adding in a progressBarLabel->setVisible(false); before the setText calls and a progressBarLabel->setVisible(True); after in bitcoingui.cpp?
That commit is mostly just changing around strings, I don't see any obvious behavioral differences except the visibility calls in the diff. (I'm gui dumb, so this might just be a snipe hunt)
Perhaps this code needs clientModel ? clientModel->getBlockSource() : BLOCK_SOURCE_NONE, which I removed, because I had the impression that function could only be called, if clientModel is already set.
I just can think of ClientModel::updateTimer() beeing faster here?
Well, connect(model, SIGNAL(numBlocksChanged(int,int)), this, SLOT(setNumBlocks(int,int))); is only called if we already HAVE a clientModel, so that can't be the problem...
Great find @rdponticelli.
I think we should revert that pull before the 0.8.2 release and later figure out why and how and re-merge a fixed version.
#2661 seems to fix this. It restores previous behaviour on the special case my tests were triggering.
Closing, as this is likely an incompatibility problem between qt and qemu/kvm, or a bug somewhere on those codebases. Some other qt based software, as kde, doesn't seem to work at all on qemu/kvm.
I'll reopen the issue if I find some way to fix/workaround this.