|
Title: bugs, domination and locking... oh my! Post by: mizerydearia on August 23, 2010, 05:29:20 PM Quote <Insti> necrodearia the market updates seem to have stopped.<necrodearia> Insti: I think it is related to all of a sudden since sometime yesterday Bitcoin started hogging an extra 3-5khash/sec and slowing my system to a crawl, including my webserver. <necrodearia> I am not sure what could affect it. I am running same version of client as I was previously and I haven't changed any system settings or softwares. <necrodearia> Although, a couple days ago X desktop crashed and I had to restart things, and maybe some software that I had updated previously are now running as a new version than was before. <necrodearia> anonymous: Have you discussed with satoshi or others regarding the bug you discovered? <anonymous> nope <anonymous> there is no bugtracker :p <Insti> what was the bug? <anonymous> a bug crashing linux client <warner> necrodearia: are you maybe running two simultaneous copies? <anonymous> and crashing windows thread <necrodearia> warner, No, I am running only one instance of Bitcoin. <necrodearia> I have previously tried running two instances of Bitcoin and I noticed that one of the instances dominated with ~95-99% generation rate, whilst the other suffered with 1-5% generation rate. There was no equilibrium. <warner> yay db locking <necrodearia> Each instance had their own .bitcoin directory, both run as separate users. <necrodearia> separate/different <necrodearia> In a premature previous attempt over a month ago I had ran two instances as same user, one instance compiled to use different ports, and in doing so I had corrupted the database file. <warner> ah, so boo no db locking :) <necrodearia> If db locking is implemented now, it was before db locking. bugs: satoshi, I am not certain of best methods for disclosing details of bugs, exploits, however, it seems that there may not be a recognizable way in doing so? Maybe email is not suitable for such things? In any case, perhaps pming anonymous (or for them to pm you) would be helpful to resolve the bug asap. It seems serious and there has been a publicly disclosed crash output that can potentially be used by malicious others to reverse engineer and reproduce the method to crash and cause serious havoc on other Bitcoin users. domination: I am running `nice -n 19 ./bitcoin -server -4way` on linux system. For a while I hadn't observed any system performance issues, but since sometime yesterday it has been very noticeable and slowing my system to a crawl. I am not sure how to diagnosse the issue other than that closing Bitcoin client resolves the system instability. locking: Is there an implementation to lock the associated database file when an instance of Bitcoin is running? Title: Re: bugs, domination and locking... oh my! Post by: vess on August 23, 2010, 10:14:24 PM I have a related set of problems, but the other way -- bitcoin on ubuntu 10.04 x64 is extremely reticent to use all available CPU time, but in a totally non-repeatable way: sometimes it will use only 1/8 or 1/4 of my 4 cores available time, never triggering CPU speed increases. other times, it cheerfully chugs along full speed ahead at full speed. This is on a Core i5 laptop.
Older versions of the client would zoom up to 100% pretty consistently, and back off when I needed, but 0.3.10 doesn't seem interested in taking up the right amount of processor time.. renice -5 has no appreciable impact -- it seems like the rate limiting functions got an update, and it's not as good as the old setup. Title: Re: bugs, domination and locking... oh my! Post by: lfm on August 24, 2010, 06:37:49 AM I have a related set of problems, but the other way -- bitcoin on ubuntu 10.04 x64 is extremely reticent to use all available CPU time, but in a totally non-repeatable way: sometimes it will use only 1/8 or 1/4 of my 4 cores available time, never triggering CPU speed increases. other times, it cheerfully chugs along full speed ahead at full speed. This is on a Core i5 laptop. Older versions of the client would zoom up to 100% pretty consistently, and back off when I needed, but 0.3.10 doesn't seem interested in taking up the right amount of processor time.. renice -5 has no appreciable impact -- it seems like the rate limiting functions got an update, and it's not as good as the old setup. I think this is a known problem with the Linux kernel. I believe something similar was a problem with the GIMPS (Mersenne prime search) project. |