Finally an easy one. I see a way that could happen on a long operation such as the initial download. The TryLock bug is unrelated to the db stuff. Fix will be in test8.
I’ve been able to reproduce the db::open/close exception 3 times now on 32-bit linux by hitting it with a continuous flood of non-stop requests. It looks like even periodically closing the wallet.dat database to flush it gets the db::close exceptions. I’m disabling the wallet flush feature on Linux. On Linux we’ll never close a database handle until we’re ready to exit. So far with this disabled, no exceptions.
I’m also implementing the orderly initial block download. Instead of naively requesting all the blocks at once, it’ll request batches of 500 at a time. This way, it’ll receive the blocks before the retry timeout, so it shouldn’t go requesting it from other nodes unless it actually doesn’t receive them or it’s too slow. The change is in the requestee’s side, so this functionality won’t be visible until your initial block download is coming from a node that has the new version.
I’m going to test this some more before sending test8.
Liberty Standard wrote:
I started with a fresh data directory with test7. Blocks started to download much faster. It only took about 15 seconds where it took a few minutes previously with the Linux build. It crashed once while it was downloading blocks with the following message in the terminal.
../include/wx/thrimpl.cpp(50): assert “m_internal” failed in TryLock(): wxMutex::TryLock(): not initialized [in child thread] Trace/breakpoint trap
I’ve included my log file, but I forgot to back it up before restarting bitcoin, so I’m not sure at what point in the log file the crash occurred.
Fortunately I haven’t encountered the segmentation fault yet. The frequency of segmentation faults in the previous builds varied quite a bit, so I’ll keep running it and let you know if i run into any problems.
On Tue, Nov 17, 2009 at 5:41 AM, Satoshi Nakamoto <satoshin@gmx.com mailto:satoshin@gmx.com> wrote:
test 7: Backup your data directory before running this, just in case. Workaround for the Db::open/Db::close "Bad file descriptor" exception. Might also make the initial block download faster. The workaround is to open the database handles and keep them open for the duration of the program, which is actually the more common thing to do anyway. If we're not closing and opening all the time, the error shouldn't get a chance to happen. The one exception is wallet.dat, which I still close after writing is finished so I can flush the transaction logs into the dat file, making the dat file standalone. That way if someone does a backup while Bitcoin is running, they'll get a wallet.dat that is valid by itself without the database transaction logs. This is a restructuring of the database handling, so we might find some new deadlocks. Usually if it deadlocks, either the UI will stop repainting, or it'll stop using CPU even though it still says Generating.
Source: Published by Martti Malmi on GitHub in February 2024 as part of his testimony in the COPA v. Wright trial. The full correspondence archive is available at mmalmi.github.io/satoshi/.