Topic: Ready for testing: 0.7.1 release candidate 1 (Read 6948 times)
indeed, also happens with RPC, not only with debug console. Not sure, though, if any other command is affected, too.
I'm test-running 0.7.1rc1 (self-compiled with libdb5.1 and without upnp on linux)
and found it drop dead already twice after sending it commands in the debug-console.
This (2nd) time it was the "move" command.
I instantly saw the mining-activity stop (cpu-meter in the panel), and the move
command didn't return a response. When it happened, I could still type more commands
in the console (though without getting an answer), but meanwhile also the debug-widget
has dropped dead and doesn't redraw anymore. I'll leave it stuck for a while and will look
back in this thread for debugging instructions before killing&restarting it...
PS: gdb says, it's stuck in pthreads_cond_wait in boost::unique_lock
in AddressTableModel::labelForAddress(QString)
in TransactionTableModel::lookupAddress(string,bool)
and found it drop dead already twice after sending it commands in the debug-console.
This (2nd) time it was the "move" command.
I instantly saw the mining-activity stop (cpu-meter in the panel), and the move
command didn't return a response. When it happened, I could still type more commands
in the console (though without getting an answer), but meanwhile also the debug-widget
has dropped dead and doesn't redraw anymore. I'll leave it stuck for a while and will look
back in this thread for debugging instructions before killing&restarting it...
PS: gdb says, it's stuck in pthreads_cond_wait in boost::unique_lock
in AddressTableModel::labelForAddress(QString)
in TransactionTableModel::lookupAddress(string,bool)
Interesting. One of my nodes has been doing the same thing in response to the RPC move command.
I get an error message saying:
Is this expected? I've had to download the block chain from scratch a couple of times previously when I've upgraded. Is it because it uses a newer version of BDB?
Here's the solution to this issue (for the record):Code:
Error initializing database environment /home/rune/.bitcoin!
To recover, BACKUP THAT DIRECTORY, then remove
everything from it except for wallet.dat.
To recover, BACKUP THAT DIRECTORY, then remove
everything from it except for wallet.dat.
Is this expected? I've had to download the block chain from scratch a couple of times previously when I've upgraded. Is it because it uses a newer version of BDB?
Quote
If you were running on Linux with a version that might have been compiled
with a different version of Berkeley DB (for example, if you were using an
Ubuntu PPA version), then run the old version again with the -detachdb
argument and shut it down; if you do not, then the new version will not
be able to read the database files and will exit with an error.
https://bitcointalksearch.org/topic/bitcoin-qtbitcoind-version-071-released-119277 with a different version of Berkeley DB (for example, if you were using an
Ubuntu PPA version), then run the old version again with the -detachdb
argument and shut it down; if you do not, then the new version will not
be able to read the database files and will exit with an error.
I'm test-running 0.7.1rc1 (self-compiled with libdb5.1 and without upnp on linux)
and found it drop dead already twice after sending it commands in the debug-console.
This (2nd) time it was the "move" command.
I instantly saw the mining-activity stop (cpu-meter in the panel), and the move
command didn't return a response. When it happened, I could still type more commands
in the console (though without getting an answer), but meanwhile also the debug-widget
has dropped dead and doesn't redraw anymore. I'll leave it stuck for a while and will look
back in this thread for debugging instructions before killing&restarting it...
PS: gdb says, it's stuck in pthreads_cond_wait in boost::unique_lock
in AddressTableModel::labelForAddress(QString)
in TransactionTableModel::lookupAddress(string,bool)
and found it drop dead already twice after sending it commands in the debug-console.
This (2nd) time it was the "move" command.
I instantly saw the mining-activity stop (cpu-meter in the panel), and the move
command didn't return a response. When it happened, I could still type more commands
in the console (though without getting an answer), but meanwhile also the debug-widget
has dropped dead and doesn't redraw anymore. I'll leave it stuck for a while and will look
back in this thread for debugging instructions before killing&restarting it...
PS: gdb says, it's stuck in pthreads_cond_wait in boost::unique_lock
in AddressTableModel::labelForAddress(QString)
in TransactionTableModel::lookupAddress(string,bool)
ok, regarding the URI thing: FINALLY got a successful complete sync of the main blockchain, and it worked fine. hurray!
man, virtual machines really don't like being left idle...
man, virtual machines really don't like being left idle...
well, i'm still downloading the blockchain so i'm not 100% sure of this result.
but, when clicking that URI, i'm asked if i want to allow the brwoser to open a progam, and of course i allow it. then i get the windows 7 equivalent of an hourglass... then nothing happens. no error message, not attemtp to start a second instance of bitcoin-qt. nothing.
i want to try again when i've sync'd with the live blockchain, so that'll be in another 10k blocks...
but, when clicking that URI, i'm asked if i want to allow the brwoser to open a progam, and of course i allow it. then i get the windows 7 equivalent of an hourglass... then nothing happens. no error message, not attemtp to start a second instance of bitcoin-qt. nothing.
i want to try again when i've sync'd with the live blockchain, so that'll be in another 10k blocks...
Can you please start regedit.exe and post the value of HKEY_CLASSES_ROOT\bitcoin\shell\open\command\(default) it needs to be something like "E:\Bitcoin\Client\bitcoin-qt.exe" "%1", and the %1 at the end is the most important part. You used the 0.7.1 RC1 installer, right?
Dia
Works fine for me on linux 64bit, I am running it the last 2 days or so.
It even recovered a wallet that I corrupted with this script (https://gist.github.com/3812689)
It even recovered a wallet that I corrupted with this script (https://gist.github.com/3812689)
Done, still getting the exact same error
Hey gavin,
Just tried the -salvagewallet command, to try to recover a corrupted wallet (1 bad sector) and i got this:
Don't know if it was supposed to work this way
Just tried the -salvagewallet command, to try to recover a corrupted wallet (1 bad sector) and i got this:
Don't know if it was supposed to work this way
salvagewallet not savagewallet
I get an error message saying:
Is this expected? I've had to download the block chain from scratch a couple of times previously when I've upgraded. Is it because it uses a newer version of BDB?
Code:
Error initializing database environment /home/rune/.bitcoin!
To recover, BACKUP THAT DIRECTORY, then remove
everything from it except for wallet.dat.
To recover, BACKUP THAT DIRECTORY, then remove
everything from it except for wallet.dat.
Is this expected? I've had to download the block chain from scratch a couple of times previously when I've upgraded. Is it because it uses a newer version of BDB?
Hey gavin,
Just tried the -salvagewallet command, to try to recover a corrupted wallet (1 bad sector) and i got this:
Don't know if it was supposed to work this way
Just tried the -salvagewallet command, to try to recover a corrupted wallet (1 bad sector) and i got this:
Don't know if it was supposed to work this way
well, i'm still downloading the blockchain so i'm not 100% sure of this result.
but, when clicking that URI, i'm asked if i want to allow the brwoser to open a progam, and of course i allow it. then i get the windows 7 equivalent of an hourglass... then nothing happens. no error message, not attemtp to start a second instance of bitcoin-qt. nothing.
i want to try again when i've sync'd with the live blockchain, so that'll be in another 10k blocks...
but, when clicking that URI, i'm asked if i want to allow the brwoser to open a progam, and of course i allow it. then i get the windows 7 equivalent of an hourglass... then nothing happens. no error message, not attemtp to start a second instance of bitcoin-qt. nothing.
i want to try again when i've sync'd with the live blockchain, so that'll be in another 10k blocks...
i need a URI to try clicking. where can i find one?
I slapped one up you can try: http://skypaint.com/bitcoin/fauceturi.htmlI think typing bitcoin:1.....?label=... etc into the browser address bar should work for testing, too.
We couild, however, create merged mined blockchains each using a different contender for "world's best signature algorithm", so that specuilators and hedgers can speculate and hedge regarding theoretical breakings of one or more such algorithms by picking and choosing which such chains to distribute their wealth among and in what proportions...
-MarkM-
-MarkM-
Can any Windows user, who used the 0.7.1 RC1 installer, confirm clicking URIs is working again.
Dia
Dia
i need a URI to try clicking. where can i find one?
It dies on my 10.5.8 mac....
This will be a WONTFIX, unless somebody steps up to continue supporting OSX 10.5.
I'll put a big note in the release notes that we're dropping OSX 10.5 support.
Can any Windows user, who used the 0.7.1 RC1 installer, confirm clicking URIs is working again.
Dia
Dia
works fine under win 7 64bit for several hours with browsing through most menus, tabs and dialogs.
Works for me on WinXP.
Received, sent, etc...
Received, sent, etc...
running in a virtual machine windows 7 64. (took forever to get that set up cause my windows disc is old...) currently syncing the blockchain problem free.
which is excellent, cause when i upgraded to 0.7 on my actual system i launched bitcoin-qt then quickly exited it, just making sure it'd launch. after thast it wouldn't lunch without an error. having done the same thing on .7.1, it behaves properly without issues.
which is excellent, cause when i upgraded to 0.7 on my actual system i launched bitcoin-qt then quickly exited it, just making sure it'd launch. after thast it wouldn't lunch without an error. having done the same thing on .7.1, it behaves properly without issues.
Jump to: