PROVEN - client is corrupting wallets upon exit

[camosoul]

EDIT: save yourself the trouble of reading all the douche-troll crap in this thread. If you know how to convert the base-whatever strings in a wallet.dat that has been db4.8_dump-ed, please let me know how. This is all that matters right now. If you read the rest of this crap from the idiots who always turn everything into a pissing match with me (and lose), you'll just wish you could get those minutes of your life back... Looking for actual help, not yet another wannabe Wild West mentality loser who thinks he's going to prove what a big man he is by trying to take me down...

Click Here to skip the suck.
--------------------
I was making a new wallet to send 1000 DRK into...

I had multiple console windows open.

I was watching ~/.darkcoin with an occasional "ls -lah"

1000 keys were generating.. File got up to 512K at 1001 keys.

I copied the address in "receive" to other wallet on other machine, send. Wait for mempool... Got it.

Exit darkcoin-qt on the new wallet.

ls -lah

wallet.dat is only 488K now...

WTF?

Before touching anything else, ./darkcoin-qt

Corrupted.

The client killed the file when it exited. Follow along:

1) Launched darkcoin-qt with no wallet.dat in ~/.darkcoin directory.
2) Saw wallet.dat grow to 512K @ 1001 keys.
3) Exited darkcoin-qt.
4) Saw wallet.dat shrink to 488K.
5) Launched darkcoin-qt immedaitely before doing anything else.
6) The wallet.dat it just created is corrupt.
7) Never got a chance to make a backup because you can't copy it while the client is resident. Upon exit, the file was corrupted.

Of course, since I sent the DRK from the bulk wallet to the new wallet before exiting, the DRKs are now in that corrupted wallet.

So, yet again, there is 1000DRK in a corrupted wallet that I never got a chance to make a backup of because it was destroyed by the client upon it's initial creation.

 

[coingun]

Got any other specifics about your setup? OS version? Wallet Version? Any of those would be helpful.

On a different note. I don't ever send any coins to a new wallet until I have done the following:

1. Opened the wallet and closed it successfully.
2. Opened the wallet again and run the encryption.
3. Open wallet again. Test that I can unlock it for 60 seconds and that my encryption password is working for said wallet.
4. Make a backup of the wallet after un-encrypting it. Move backup to usb. Test backup works on my wallet rescue node.
5. If all these tests go successfully I will then make the transfer to the wallet.

I know this doesn't help you in this case but perhaps you might want to revisit the process by which you get a wallet ready to go for production use. These steps should be taken by anyone protecting coins in wallets imho.

 

[camosoul]

Got any other specifics about your setup? OS version? Wallet Version? Any of those would be helpful.

On a different note. I don't ever send any coins to a new wallet until I have done the following:

1. Opened the wallet and closed it successfully.
2. Opened the wallet again and run the encryption.
3. Open wallet again. Test that I can unlock it for 60 seconds and that my encryption password is working for said wallet.
4. Make a backup of the wallet after un-encrypting it. Move backup to usb. Test backup works on my wallet rescue node.
5. If all these tests go successfully I will then make the transfer to the wallet.

I know this doesn't help you in this case but perhaps you might want to revisit the process by which you get a wallet ready to go for production use. These steps should be taken by anyone protecting coins in wallets imho.

0.10.15.16

14.04

It just made 8 in a row no problem, so I didn't do all the redundancy... Figured it was working, then, poof, it wrecks a wallet for no reason...

It's inconsistent. I'm just not doing it anymore. Can't count on it. If it ever gets stable and reliable, I'll revisit it. For now, I'm not even going to run it. Cold wallet with what's left, and forget it.

I shoulda just exported the key... Oh well. Too unreliable to do this kind of work with it. Too much work to keep up with everything it might randomly screw up for no reason...

 

[coingun]

Don't be such a drama queen. There has been extensive testing of this stuff and it is all working very well. Sure there might be some edge cases but to have a small issue and to then go swear off the whole process as "broken" cause you don't want to take the steps to protect yourself could be thought of as a childish response.

There is lots of people here to help. I have done a lot of stupid things testing this coin and never not been able to get stuff back in order. Might be time to step back and just hang on a sec while we do some triage.

 

[camosoul]

Don't be such a drama queen. There has been extensive testing of this stuff and it is all working very well. Sure there might be some edge cases but to have a small issue and to then go swear off the whole process as "broken" cause you don't want to take the steps to protect yourself could be thought of as a childish response.

There is lots of people here to help. I have done a lot of stupid things testing this coin and never not been able to get stuff back in order. Might be time to step back and just hang on a sec while we do some triage.

Did I own it or did I not own it?

I shoulda just exported the key...

I should know better. It is v0.10 after all. And, even worse, this happened to me before. I should have know better. Sucks to be me... Moving on.

I'm only posting to prove that this problem wasn't just a freak accident related to my system. It is totally random and I cannot force it to repeat, but it does happen, and it's the same damn thing as last time. I wrote it off as a fluke or problem external to the client, but it is clearly not.

The problem is consistent, triggering it seems to have no rhyme or reason. All I can do is report what happened... Don't kill the messenger.

I can't say whether this would happen only to a new wallet on first try, but that is the only time it has happened so far. I sure don't want to take the risk of blowing up a 35MB wallet full of darksent stuff... I'm just throwing it in cold storage and forgetting about it. The downside is, I have no idea if "the last time I shut down" ended up in corruption. Have to start up again to check, and then, well, you have to shut down again, and you don't know if that shutdown causes a corruption... Never can tell.

 

[coingun]

I should know better. It is v0.10 after all. And, even worse, this happened to me before. I should have know better. Sucks to be me... Moving on.

http://en.wikipedia.org/wiki/Software_versioning#Version_1.0_as_a_milestone

Important part..."the free-software community tends to use version 1.0 as a major milestone, indicating that the software is "complete", that it has all major features, and is considered reliable enough for general release."

You sir are correct. We are at v0.10. Meaning we do have a long ways to go. The coin has been under constant development for many quarters and it hasn't been without it's bumps. There has been lots of nights dumping funds to entirely new wallet.dat files upon upgrades and many other things are still a work in progress. The point is we all know this so it is even more important to use entire best practices for all steps. If you do this currently you have nothing to worry about using these wallets.

A ton of people would step up to help you with your corruption issue but since you are swearing off any usage now it leads me to wonder. Are these real issues you are actually having or just something to start the fudding? If you have truly found an issue then I know a ton of people who would love to get some debug information so the required changes/fixes can be implemented. I've seen 3 or 4 new wallet versions in a single day. Fixing another issue if it's real is a priority for all of us.

I'd suggest emailing the debug.log and the wallet.dat file to [email protected] so that he can investigate the issue directly. If you do this it will be a great way for us to know you are actually having an issue and not just fudding around in a new sandbox.

 

[camosoul]

...but since you are swearing off any usage now it leads me to wonder. Are these real issues you are actually having or just something to start the fudding?

Straw Man. Want to call me a FUDder, so, have to fabricate a reason to justify it. I never said or did this.

Where did I say "OMGz I SO ARE DUMPING!!" Show me.

I have retained the amazing, shrinking, self-destructing wallet.dat.

In cold storage, becaue I don't trust the client after seeing this happen, twice.

Having seen that happen twice, would you throw a wallet full of repeated darksends with 5 digits of DRK into a client that might blow it up? Would you?

Yeah. Cold storage != swear it off. I'm merely exercising some common-sense I should have used earlier; should have exported the key...

 

[UdjinM6]

I'd suggest emailing the debug.log and the wallet.dat file to [email protected] so that he can investigate the issue directly. If you do this it will be a great way for us to know you are actually having an issue and not just fudding around in a new sandbox find and squash that bug.

+1 but for fixed version

 

[camosoul]

2014-10-25 20:03:04 send last getblocks for 00000000000b982b1fdf7603f8cd00315a3675b1dfa2ffcf333dd28c6ce7da08 peer=13
2014-10-25 20:03:04 send last getblocks for 00000000000b982b1fdf7603f8cd00315a3675b1dfa2ffcf333dd28c6ce7da08 peer=6
2014-10-25 20:03:05 send last getblocks for 00000000000b982b1fdf7603f8cd00315a3675b1dfa2ffcf333dd28c6ce7da08 peer=7
2014-10-25 20:03:05 mnw - winning vote CTxIn(COutPoint(ed2612a8915926d51e2f1272d48b073e0a6eee1bea05fe4b4ec831bb3b463669, 0), scriptSig=) Height 158692 bestHeight 158682
2014-10-25 20:03:05 send last getblocks for 00000000000b982b1fdf7603f8cd00315a3675b1dfa2ffcf333dd28c6ce7da08 peer=9
2014-10-25 20:03:05 send last getblocks for 00000000000b982b1fdf7603f8cd00315a3675b1dfa2ffcf333dd28c6ce7da08 peer=12
2014-10-25 20:03:05 mnw - winning vote CTxIn(COutPoint(ed2612a8915926d51e2f1272d48b073e0a6eee1bea05fe4b4ec831bb3b463669, 0), scriptSig=) Height 158692 bestHeight 158682
2014-10-25 20:03:05 mnw - winning vote CTxIn(COutPoint(ed2612a8915926d51e2f1272d48b073e0a6eee1bea05fe4b4ec831bb3b463669, 0), scriptSig=) Height 158692 bestHeight 158682
2014-10-25 20:03:05 mnw - winning vote CTxIn(COutPoint(ed2612a8915926d51e2f1272d48b073e0a6eee1bea05fe4b4ec831bb3b463669, 0), scriptSig=) Height 158692 bestHeight 158682
2014-10-25 20:03:05 ProcessSyncCheckpoint: sync-checkpoint at 000000000019536ac743683e1b391315473f5615e30f45b970e39af2a0b21001
2014-10-25 20:03:05 mnw - winning vote CTxIn(COutPoint(ed2612a8915926d51e2f1272d48b073e0a6eee1bea05fe4b4ec831bb3b463669, 0), scriptSig=) Height 158692 bestHeight 158682
2014-10-25 20:03:05 mnw - winning vote CTxIn(COutPoint(ed2612a8915926d51e2f1272d48b073e0a6eee1bea05fe4b4ec831bb3b463669, 0), scriptSig=) Height 158692 bestHeight 158682
2014-10-25 20:03:05 getblocks -1 to 0 limit 500 peer=9
2014-10-25 20:03:05 mnw - winning vote CTxIn(COutPoint(ed2612a8915926d51e2f1272d48b073e0a6eee1bea05fe4b4ec831bb3b463669, 0), scriptSig=) Height 158692 bestHeight 158682
2014-10-25 20:03:05 getblocks -1 to 0 limit 500 peer=12
2014-10-25 20:03:06 getblocks -1 to 0 limit 500 peer=10
2014-10-25 20:03:06 mnw - winning vote CTxIn(COutPoint(ed2612a8915926d51e2f1272d48b073e0a6eee1bea05fe4b4ec831bb3b463669, 0), scriptSig=) Height 158692 bestHeight 158682
2014-10-25 20:03:06 getblocks -1 to 0 limit 500 peer=5
2014-10-25 20:03:16 mnw - winning vote CTxIn(COutPoint(1a8a4870ab69659e367dcd4255a900bcd9e326deaba41d7cd4fea661d47cb3bb, 0), scriptSig=) Height 158673 bestHeight 158682
2014-10-25 20:03:16 mnw - winning vote CTxIn(COutPoint(1a8a4870ab69659e367dcd4255a900bcd9e326deaba41d7cd4fea661d47cb3bb, 0), scriptSig=) Height 158673 bestHeight 158682
2014-10-25 20:03:16 mnw - winning vote CTxIn(COutPoint(1a8a4870ab69659e367dcd4255a900bcd9e326deaba41d7cd4fea661d47cb3bb, 0), scriptSig=) Height 158673 bestHeight 158682
2014-10-25 20:03:16 mnw - winning vote CTxIn(COutPoint(1a8a4870ab69659e367dcd4255a900bcd9e326deaba41d7cd4fea661d47cb3bb, 0), scriptSig=) Height 158673 bestHeight 158682
2014-10-25 20:03:16 mnw - winning vote CTxIn(COutPoint(1a8a4870ab69659e367dcd4255a900bcd9e326deaba41d7cd4fea661d47cb3bb, 0), scriptSig=) Height 158673 bestHeight 158682
2014-10-25 20:03:16 mnw - winning vote CTxIn(COutPoint(1a8a4870ab69659e367dcd4255a900bcd9e326deaba41d7cd4fea661d47cb3bb, 0), scriptSig=) Height 158673 bestHeight 158682
2014-10-25 20:03:16 mnw - winning vote CTxIn(COutPoint(1a8a4870ab69659e367dcd4255a900bcd9e326deaba41d7cd4fea661d47cb3bb, 0), scriptSig=) Height 158673 bestHeight 158682
2014-10-25 20:03:17 mnw - winning vote CTxIn(COutPoint(1a8a4870ab69659e367dcd4255a900bcd9e326deaba41d7cd4fea661d47cb3bb, 0), scriptSig=) Height 158673 bestHeight 158682
2014-10-25 20:03:35 dseep: Couldn't find masternode entry CTxIn(COutPoint(5ee0d272e864bf838b685f45e60e0b20123cb1c6ebbd36512d3f5afa25ef7faf, 0), scriptSig=)
2014-10-25 20:03:35 dseep: Couldn't find masternode entry CTxIn(COutPoint(5ee0d272e864bf838b685f45e60e0b20123cb1c6ebbd36512d3f5afa25ef7faf, 0), scriptSig=)
2014-10-25 20:03:35 dseep: Couldn't find masternode entry CTxIn(COutPoint(5ee0d272e864bf838b685f45e60e0b20123cb1c6ebbd36512d3f5afa25ef7faf, 0), scriptSig=)
2014-10-25 20:03:35 dseep: Couldn't find masternode entry CTxIn(COutPoint(5ee0d272e864bf838b685f45e60e0b20123cb1c6ebbd36512d3f5afa25ef7faf, 0), scriptSig=)
2014-10-25 20:03:35 dseep: Couldn't find masternode entry CTxIn(COutPoint(5ee0d272e864bf838b685f45e60e0b20123cb1c6ebbd36512d3f5afa25ef7faf, 0), scriptSig=)
2014-10-25 20:03:35 dseep: Couldn't find masternode entry CTxIn(COutPoint(5ee0d272e864bf838b685f45e60e0b20123cb1c6ebbd36512d3f5afa25ef7faf, 0), scriptSig=)
2014-10-25 20:03:35 dseep: Couldn't find masternode entry CTxIn(COutPoint(5ee0d272e864bf838b685f45e60e0b20123cb1c6ebbd36512d3f5afa25ef7faf, 0), scriptSig=)
2014-10-25 20:03:36 dseep: Couldn't find masternode entry CTxIn(COutPoint(5ee0d272e864bf838b685f45e60e0b20123cb1c6ebbd36512d3f5afa25ef7faf, 0), scriptSig=)
2014-10-25 20:03:37 received block 00000000000568d70286cd6cb96a3729f0e42d79e432f86dfa7eb5177f5965fb peer=12
2014-10-25 20:03:37 CheckBlock() : Couldn't find masternode payment(0) or payee(1).
2014-10-25 20:03:37 CheckBlock() : Couldn't find masternode payment(0) or payee(1).
2014-10-25 20:03:37 Committing 39 changed transactions to coin database...
2014-10-25 20:03:37 SetBestChain: new best=00000000000568d70286cd6cb96a3729f0e42d79e432f86dfa7eb5177f5965fb height=158683 log2_work=60.304869 tx=617526 date=2014-10-25 20:03:10 progress=1.000000
2014-10-25 20:03:37 send last getblocks for 00000000000568

I included the end of the debug.log.

Nothing useful in the debug.log except the glaring omission of normal shutdown process. It just abruptly ends. That's all.

Closed darkcoin-qt by usual shutdown from tray, didn't kill process or any other such stupidity...

 

[coingun]

Straw Man. Want to call me a FUDder, so, have to fabricate a reason to justify it. I never said or did this.

Where did I say "OMGz I SO ARE DUMPING!!" Show me.

I have retained the amazing, shrinking, self-destructing wallet.dat.

In cold storage, becaue I don't trust the client after seeing this happen, twice.

Having seen that happen twice, would you throw a wallet full of repeated darksends with 5 digits of DRK into a client that might blow it up? Would you?

Yeah. Cold storage != swear it off. I'm merely exercising some common-sense I should have used earlier; should have exported the key...

I guess the part that throws me off is your title is, "PROVEN - client is corrupting wallet upon exit". Usually when something is proven there is proof. We don't even have any debug info from you to give to a developer that could fix the problem if any problem existed. When I see a title like PROVEN then realize the person didn't even take the time to backup I guess I tend to wonder about their definition of PROVEN.

Please don't take my responses the wrong way. I am just trying to get the very basic's of information from you so that the entire community can help. My question now is if you are going to use the word PROVEN client corruption. Then help us by taking the time to submit debugging info.

Putting funds into a Darkcoin wallet.dat file that never has any ds+ stuff even run on it at this point is entirely safe.

 

[camosoul]

When I see a title like PROVEN then realize the person didn't even take the time to backup I guess I tend to wonder about their definition of PROVEN.

Straw Man #2: If you read it, you'd know I never got a chance to make a backup. Just like last time.

Making stuff up, then attacking the stuff you made up. This is classic Straw Man trolling. Unhelpful.

Can't copy the wallet.dat while client is running. Client destroys wallet.dat upon exiting. Can't make a backup, duh.

I COULD have exported the key while the client was live, before it exited and destoyed the wallet.dat... But since it did the job just fine so many times, and the last time this happened it was written off as not the client's fault... I didn't do it.

debug.log entirely unhelpful. Included the tail anyway. As you can see, the only information we get is that it didn't shutdown as it was told, it just disappeared from RAM without performing it's usual shutdown stuff. debug.log shows us only a lack of something. None of the content is unusual or helpful. All we have to go on is that which is conspicuously missing.

 

[coingun]

Straw Man #2: If you read it, you'd know I never got a chance to make a backup. Just like last time.

Making stuff up, then attacking the stuff you made up. This is classic Straw Man trolling. Unhelpful.

Weird I was just thinking using the word PROVEN (in all caps) and then not actually providing any proof seemed a bit like trolling. Perhaps not Straw Man trolling but maybe some other category?

 

[camosoul]

Weird I was just thinking using the word PROVEN (in all caps) and then not actually providing any proof seemed a bit like trolling. Perhaps not Straw Man trolling but maybe some other category?

I did provide proof, you just don't like it.

Here it is:

1) Launched darkcoin-qt with no wallet.dat in ~/.darkcoin directory.
2) Saw wallet.dat grow to 512K @ 1001 keys.
3) Exited darkcoin-qt.
4) Saw wallet.dat shrink to 488K.
5) Launched darkcoin-qt immedaitely before doing anything else.
6) The wallet.dat it just created is corrupt.
7) Never got a chance to make a backup because you can't copy it while the client is resident. Upon exit, the file was corrupted.

Now, if you're done building obvious Straw Men, and having me call you out for it, have a nice day; maybe someone who wants to help instead of troll will come along... This is a useless troll argument.

If someone would tell me how to make the corrupted wallet.dat human-readable, I could then just search for the address as a string, private key can't be far away from that... Wallet it was sent from obviously knows the address that was sent to... Can find this if I can make it human-readable.

 

[crowning]

The client killed the file when it exited. Follow along:

1) Launched darkcoin-qt with no wallet.dat in ~/.darkcoin directory.
2) Saw wallet.dat grow to 512K @ 1001 keys.
3) Exited darkcoin-qt.
4) Saw wallet.dat shrink to 488K.
5) Launched darkcoin-qt immedaitely before doing anything else.
6) The wallet.dat it just created is corrupt.

I use the official v0.10.15.16 binary and can't reproduce it here. OS is Ubuntu 14.04.
Care to share a bit more background information?

7) Never got a chance to make a backup because you can't copy it while the client is resident. Upon exit, the file was corrupted.

Of course, since I sent the DRK from the bulk wallet to the new wallet before exiting, the DRKs are now in that corrupted wallet.

So, yet again, there is 1000DRK in a corrupted wallet that I never got a chance to make a backup of because it was destroyed by the client upon it's initial creation.

That's why I ALWAYS make a backup of the NEW wallet beforehand, check that backup and only send the funds when everything is correct.

And, checking includes trying out the password!

 

[coingun]

Just setting up a test environment so I didn't test this but a couple google searches on human read-able wallet.dat found this...

--- paste incoming
First, this will only work if you used the encrypt wallet function of 0.6.0rc1.
Second, make a backup.

• Run: db4.8_dump -p wallet.dat >wallet.txt (to create a human readable wallet dump)
• Open wallet.txt using your favorite text editor.
• Search for lines starting with "\03key". There should only be a few of them.
• Delete those \03key lines, as well as the 1 line that follows each.
• Now search for lines starting with "\04pool". There should be +- 100.
• Delete those \04pool lines, as well as the 1 line that follows each.
• Import the purged dump again: db4.8_load -f wallet.txt wallet.dat.new
• Replace wallet.dat with wallet.dat.new, and start bitcoin.

--- paste done

Didn't test any of this as I said. You're a linux guy though so we can race to build the deps. Oh maybe make a backup first?

 

[camosoul]

I'd suggest emailing the debug.log and the wallet.dat file to [email protected] so that he can investigate the issue directly. If you do this it will be a great way for us to know you are actually having an issue and not just fudding around in a new sandbox.

Really? Dump my shit on Evan is how I prove to you I'm not a troll? If I were a dev, that's not an email I would want to get in the middle of doing other things. Distractions.

I'm under no obligation to prove my veracity to someone who has already proved himself to be a troll. And certainly not by bothering the dev with it. You're just one bad idea/invented argument after another...

If I'm making it up, ignore it.

 

[camosoul]

I use the official v0.10.15.16 binary and can't reproduce it here. OS is Ubuntu 14.04.
Care to share a bit more background information?

There isn't anything else to tell. That's part of the problem... I had just done the same thing 8 times in a row with no issues. Then poof... debug.log only shows an abrupt end to logging, not the normal shutdown stuff. That and the shrinking of the wallet.dat at the same moment is all I've got to tell. This is exactly what happened last time. It's random and rare, but the problem at least presents consistently when it does present... I have no idea how to reproduce it because there seems to be nothing that causes it. I did the exact same thing 8 times in a row prior to this incident and it didn't happen... Just keep doing it until it happens? I have no idea. I'm reporting what happened.

Don't get mad because it's bad news and you'd rather write it off because you want to pump price. I let that happen last time and guess what? This shit happened again. It's not a fluke.

That's why I ALWAYS make a backup of the NEW wallet beforehand, check that backup and only send the funds when everything is correct.

A partly valid point, but how do I know it won't corrupt it the second time? It happens upon exit... So, will it be this time I exit? Or next time?

Should have exported the key... Essentially, a way to make a backup without exiting. Then I have the key no matter what happens. But I didn't do that...

 

[coingun]

Really? Dump my shit on Evan is how I prove to you I'm not a troll? If I were a dev, that's not an email I would want to get in the middle of doing other things. Distractions.
I'm under no obligation to prove my veracity to someone who has already proved himself to be a troll. And certainly not by bothering the dev with it. You're just one bad idea/invented argument after another...

If I'm making it up, ignore it.

....
DarkcoinBot> coingun: 1000.0 DRK @ 0.00556468 DRK/BTC (source:cryptsy|54s) = 5.564680 BTC / 1952.48 USD (source:bitstamp:1m13s)
....

It's $1952.48 USD we are talking about here. You aren't dumping anything on anyone. You made a mistake we all do not backing up before sending. I know I wouldn't have any issue stopping what I was doing to help with that type of money on the line. You don't have to prove anything to anyone. You used the word PROVEN corruption which is a fairly strong accusation that scares a lot of people so we just want to address it properly and give it the attention it deserves.

If it was PROVEN corruption then I'd expect it be fully reproducible on a 10.15.16 client running on 14.04 after making 8 wallet files the 9th should corrupt. This is the test we are running right?

 

[Scriptiee]

Unable to recreate on Arch with the latest client either.


Edit: Gonna give it a go tomorrow again, camosoul should send your debug to Evan, he would be the one to make the most of it.

 

[camosoul]

If it was PROVEN corruption then I'd expect it be fully reproducible on a 10.15.16 client running on 14.04 after making 8 wallet files the 9th should corrupt. This is the test we are running right?

No. And doing that won't prove anything. Pay attention.

This happened once before on a much, much older version.

Another Straw Man, because I've said this is the second time, and the first time we are all well aware of. I just let it slide because all the pumpers were throwing a fit about it. I even believed them when it was suggested the problem was elsewhere. Propulsion recovered it for me. I was told by two different people that it was caused by two different things that I did not do, and that it was my fault, even thought I did not do what they said I did to cause it, and only one of them could have been true... So, neither of them were right about the problem, or that I caused it.

Same problem, same symptoms.

Same price pumper trolls mad that I'm talking about it, skipping over useful info, pretending not to understand, etc...

This has to be related to a piece of code that hasn't been touched in a very long time, and has been the same in all clients for many months now.

You have a very poor grasp of scientific method...

Will try the dump, had no idea that even existed.