I think the following might fix the crash: diff --git a/cppForSwig/BlockUtils.cpp b/cppForSwig/BlockUtils.cpp index 2b08f5e..bf270bf 100644 --- a/cppForSwig/BlockUtils.cpp +++ b/cppForSwig/BlockUtils.cpp @@ -2535,6 +2535,7 @@ uint32_t BlockDataManager_FileRefs::parseEntireBlockchain( string blkdir, bsb.reader().advance(nextBlkSize); } } + globalCache.openFile(fnum-1, blkfile); TIMER_STOP("ScanBlockchain"); } i.e. re-open the file after loading its contents, causing the value in fileSizes_ to be updated in the event that the blockchain data file has grown while being read. I don't see how that would prevent the crash while loading the blockchain that I saw once, but I'm hoping it will fix the much more common crash while looping through the blocks. I'll let you know how it goes. Edit: Here's output from the loading the blockchain with a couple of extra print statements to show the cached file sizes: Opening file 1: /home/chris/.bitcoin//blk0001.dat fileSizes_[0] = 2097307549 Opening file 2: /home/chris/.bitcoin//blk0002.dat fileSizes_[1] = 252024334 Highest blkXXXX.dat file: 2 Attempting to read blockchain from file: /home/chris/.bitcoin//blk0001.dat /home/chris/.bitcoin//blk0001.dat is 2000.15 MB fileSizes_[0] unchanged after reading file fileSizes_[0] = 2097307549 Attempting to read blockchain from file: /home/chris/.bitcoin//blk0002.dat /home/chris/.bitcoin//blk0002.dat is 240.362 MB fileSizes_[1] changing from 252024334 to 252037572 fileSizes_[1] = 252037572 Organizing chain Done organizing chain Loading blockchain took 104.0 sec
|
|
|
But it looks like you got the crash somewhere relevant before.
I just had it crash again, after the initial blockchain load, and well into looping through the blocks. At the time of the crash, my blockchain file sizes are like this: -rw------- 1 chris chris 2 097 307 549 Jul 12 20:07 blk0001.dat -rw------- 1 chris chris 251 261 998 Jul 29 15:35 blk0002.dat And the line that causes the crash is: if( cidx >= openFiles_.size() || cstart + cbytes > fileSizes_[cidx] ) According to gdb, at the time of the crash: (gdb) p fileSizes_[cidx] $8 = (unsigned int &) @0xf78854: 251 117 353 (gdb) p cstart $9 = 251 225 041 So the problem seems to be caused by the code trying to retrieve from a block which has arrived since the blockchain was initially loaded. Can you think of a reason that might be happening? How would the Armory code know about the newly arrived block? Are you loading the blkindex.dat at all? That could be an explanation if the blkindex.dat is out of sync with the blk00*.dat files, but I'm not seeing you loading the index file at all. Edit: I think the problem is caused when the blockchain files grow in size while being read. The code caches the size of both files, then reads both files. While reading the first file, there's plenty of time for the 2nd file to grow, ending up with blocks outside of the range defined by the file sizes that were cached.
|
|
|
I expect what happened was that your winnings were paid out using the change from someone else's losing bet, and that their losing bet ended up never being confirmed. There seem to be 8 bets which haven't been paid out after a reasonable length of time: 18455d8b2020cef49579fa2f024375a43e242f4bb0c303cba526327944c65e46 6071357b4e24964f398de274e55c85cadaf33e1f54acaa284a7dfc23933feff3 72b97a20c5cee0b9f05b5203d0361263edb41b752a15e2838ac2b3b6789f74c2 981ad49041b2b7c8c05d76b7a62eba4a47ed9dd6aed5a276ad219a0706244821 ad4866a91ce24c624f3582aa87b19cd8e55361c31315b9d79d80084730697c14 b9f59df309d00e491ec2783690e47665cde57d20517f7d2ef170536ab4f2af7a bea477ad898c961642876207e65c0f7700581e3c839987e5de151dd640a7eaa0 c9cca3a9e5a1494cee2c87c950c1283f83d091920cb6e6749b3e5930d8d69ac2That's a lot better than it used to be - SatoshiDice seems to be working a lot better in general these days than it used to. Hopefully FireDuck will look at these 8 bets and resolve them soon.
|
|
|
payb.tc runs bitcoinmax.com, which is a PPT but it's independent of GLBTSE.
From the horse's mouth: i know that one of the things people like about bitcoin max is not having to deal with gblse, and i can totally understand that, because i don't want to either. i don't have an account there and it seems way too complicated, and to be honest, it seems like too much effort.
|
|
|
- pay.btc (runs PiratePassThrough Bond on GLBSE or is affiliated with one)
payb.tc runs bitcoinmax.com, which is a PPT but it's independent of GLBTSE. Just in case anyone cares about facts, y'know?
|
|
|
I don't know whether I'm being really slow here or if you're not making sense, but what are you trying to say?
Someone posted a twitter link with an affiliate ID in it?
|
|
|
Results: 2012-Jul-28 05:03pm (up to block 191263)
Address Target Should Win | #Bets | Win | Lose | Refunds | BTC In | BTC Out | Refund | Profit | RTP -------------------------------------------------------------------------------------------------------------------------------------------- 1dice1e6p 1 0.00002 | 11300 | 0 (0.00000) | 11016 | 284 | 68.67 | 0.01 | 18.39 | 68.65 | 0.028 1dice1Qf4 2 0.00003 | 1080 | 0 (0.00000) | 1010 | 70 | 15.10 | 0.00 | 5.58 | 15.10 | 0.012 1dice2pxm 4 0.00006 | 1643 | 0 (0.00000) | 1609 | 34 | 19.87 | 0.02 | 2.22 | 19.84 | 0.104 1dice2vQo 8 0.00012 | 1350 | 1 (0.00076) | 1309 | 40 | 31.55 | 8.05 | 4.15 | 23.50 | 25.516 1dice2WmR 16 0.00024 | 1657 | 1 (0.00062) | 1623 | 33 | 65.51 | 4.19 | 7.40 | 61.32 | 6.399 1dice2xkj 32 0.00049 | 4048 | 2 (0.00050) | 4035 | 11 | 258.88 | 102.98 | 1.29 | 155.90 | 39.780 1dice2zdo 64 0.00098 | 5822 | 8 (0.00138) | 5797 | 17 | 288.45 | 122.97 | 55.64 | 165.48 | 42.631 1dice37Ee 128 0.00195 | 6819 | 17 (0.00251) | 6754 | 48 | 1276.46 | 1173.85 | 40.25 | 102.61 | 91.961 1dice3jkp 256 0.00391 | 5763 | 27 (0.00470) | 5722 | 14 | 616.02 | 382.08 | 13.11 | 233.93 | 62.025 1dice4J1m 512 0.00781 | 8829 | 63 (0.00714) | 8761 | 5 | 1738.30 | 1089.80 | 9.35 | 648.50 | 62.693 1dice5wwE 1000 0.01526 | 15637 | 233 (0.01490) | 15401 | 3 | 2754.44 | 2449.38 | 1.80 | 305.05 | 88.925 1dice61SN 1500 0.02289 | 8961 | 210 (0.02345) | 8745 | 6 | 3255.89 | 3665.55 | 15.00 | -409.66 | 112.582 1dice6DPt 2000 0.03052 | 11275 | 353 (0.03132) | 10919 | 3 | 3646.23 | 3354.52 | 9.24 | 291.71 | 92.000 1dice6gJg 3000 0.04578 | 8908 | 427 (0.04797) | 8474 | 7 | 5216.56 | 6683.19 | 24.99 | -1466.62 | 128.115 1dice6GV5 4000 0.06104 | 10004 | 621 (0.06209) | 9380 | 3 | 3419.84 | 3170.09 | 31.20 | 249.75 | 92.697 1dice6wBx 6000 0.09155 | 16999 | 1607 (0.09459) | 15383 | 9 | 9072.46 | 9216.16 | 7.01 | -143.69 | 101.584 1dice6YgE 8000 0.12207 | 36575 | 4516 (0.12352) | 32046 | 13 | 6988.81 | 6224.50 | 0.00 | 764.30 | 89.064 1dice7EYz 12000 0.18311 | 16685 | 3171 (0.19012) | 13508 | 6 | 6886.12 | 7051.57 | 14.50 | -165.44 | 102.403 1dice7fUk 16000 0.24414 | 45701 | 11086 (0.24262) | 34607 | 8 | 15975.11 | 16674.57 | 347.79 | -699.45 | 104.378 1dice7W2A 24000 0.36621 | 34264 | 12671 (0.37015) | 21561 | 32 | 15694.96 | 15690.03 | 212.63 | 4.92 | 99.969 1dice8EMZ 32000 0.48828 | 321674 | 156724 (0.48742) | 164816 | 134 | 102229.80 | 102692.64 | 2173.21 | -462.84 | 100.453 1dice97EC 32768 0.50000 | 135347 | 67518 (0.49918) | 67741 | 88 | 54948.38 | 53182.77 | 789.20 | 1765.61 | 96.787 1dice9wcM 48000 0.73242 | 102305 | 75226 (0.73572) | 27022 | 57 | 90118.49 | 88509.89 | 467.98 | 1608.59 | 98.215 1dicec9k7 52000 0.79346 | 1818 | 1465 (0.80583) | 353 | 0 | 4312.15 | 4492.53 | 0.00 | -180.38 | 104.183 1dicegEAr 56000 0.85449 | 1116 | 939 (0.84215) | 176 | 1 | 1307.62 | 1318.74 | 0.00 | -11.12 | 100.850 1diceDCd2 60000 0.91553 | 506 | 466 (0.92644) | 37 | 3 | 318.73 | 316.55 | 0.00 | 2.18 | 99.316 1dice9wVt 64000 0.97656 | 6047 | 5791 (0.97871) | 126 | 130 | 5148.47 | 4951.10 | 239.20 | 197.36 | 96.166 -------------------------------------------------------------------------------------------------------------------------------------------- | 822133 | 343143 | 477931 | 1059 | 335673.00 | 332527.85 | 4491.23 | 3145.14 | 99.063 --------------------------------------------------------------------------------------------------------------------------------------------
SD Profit before fees: 3145.14824664 BTC (0.937%) Cumulative Fees Paid: 413.90882500 BTC SD Profit after fees: 2731.23942164 BTC (0.814%) ---- Since Satoshi Dice started, there have been: Blockchain Tx: 2509244 : SatoshiDice Tx: 1513290 (60.3%) Blockchain MB: 1057.0 : SatoshiDice Tx: 622.2 (58.9%)
|
|
|
Retype your user name.
When reading from registry, I change the size so getting bogus characters, sorry.
That worked, thanks. Actually I just deleted the junk from the end of my name rather than retyping it.
|
|
|
dooglus:
We have a limit of 64 character passwords, but the issue was not you. We found the error in the software and will be resolved on your next update.
I ran PM Poker again. It did an update. Then it showed this screen: https://i.imgur.com/Q3XNi.pngI didn't type that long username - that's what it defaulted to. Is that my new username? Or should I change it back to 'dooglus'? I left my username as it was, and typed in my password. It told me to 'contact support', but didn't tell me how. There's no information on the website that I could see about how to 'contact support'.
|
|
|
When I run it on Ubuntu using wine, every time I click something I get a message saying ".256 is not a float" Several of them, just the number changes.
Interesting. I'm using WINE (1.4-0ubuntu4.1) in Ubuntu (12.04, 64 bit) and don't have that issue. What version of WINE and Ubuntu are you using?
|
|
|
dooglus:
We have a limit of 64 character passwords, but the issue was not you. We found the error in the software and will be resolved on your next update.
I ran PM Poker again. It did an update. Then it showed this screen: I didn't type that long username - that's what it defaulted to. Is that my new username? Or should I change it back to 'dooglus'?
|
|
|
However, if it doesn't crash at that conditional, I'll have to do some work to add some extra conditions and re-run the sample_armory_code.py script over and over until it crashes.
I wanted it to crash while loading the blockchain. So I put an infinite loop around the BDM_LoadBlockchainFile() call, and ran TheBDM.Reset() after each load so it would continually reload the blockchain. I left it running overnight. It loaded the blockchain 125 times but didn't trigger the breakpoint once.
|
|
|
Chen Jianhai is my previous business associate. If he has been in business with this guy then what business was it ? Unless you consider credit card fraud a business. tldr you can tell a lot about people by the company they keep. I know none of my previous "business associates" are international fraudsters Your tl;dr was longer than the post it attempted to summarise.
|
|
|
I've only ever seen it crash once when loading the blockchain. Usually the crash happens after processing lots of blocks. I put the breakpoint in place and finally it crashed. Here's what I found: Sat Jul 28 01:04:51 2012 UNDER 24000 BLOCK 191118 TX e7b4a0ececfa3cad6b76b7ea622b3cabb5e8aa386c7069e05c7859bbb6e036cc BET 6.80000000 LOSE -6.76650000 Sat Jul 28 01:04:51 2012 UNDER 24000 BLOCK 191118 TX 2cc561544ae99d2339d4ff85c25005e8b9edc3aecbd2f5c7c54a118cd7edf268 BET 43.80000000 LOSE -43.58150000 Sat Jul 28 01:04:51 2012 UNDER 24000 BLOCK 191118 TX bbf25561526aa2e64ab1820e22f1c76fe0ec8d13ef7e5495566079c5c7b310ae BET 70.00000000 LOSE -69.65050000 .....FileDataPtr.h:291 return NULL
Breakpoint 1, FileDataCache::getCachedDataPtr (this=0x7ffff585a3e0, fdref=...) at FileDataPtr.h:292 292 return NULL; (gdb) where #0 FileDataCache::getCachedDataPtr (this=0x7ffff585a3e0, fdref=...) at FileDataPtr.h:292 #1 0x00007ffff52acef2 in FileDataPtr::getUnsafeDataPtr (this=0x31df6218) at FileDataPtr.cpp:25 #2 0x00007ffff52b4400 in TxRef::getTxCopy (this=0x31df6218) at BlockObj.cpp:718 #3 0x00007ffff545be19 in _wrap_TxRef_getTxCopy (args=0x7ffff7eda0d0) at CppBlockUtils_wrap.cxx:35980 #4 0x000000000042a485 in PyEval_EvalFrameEx () #5 0x000000000042abe2 in PyEval_EvalFrameEx () #6 0x00000000004317f2 in PyEval_EvalCodeEx () #7 0x000000000054b171 in PyRun_FileExFlags () #8 0x000000000054b7d8 in PyRun_SimpleFileExFlags () #9 0x000000000054c5d6 in Py_Main () #10 0x00007ffff68e576d in __libc_start_main (main=0x41b900 <main>, argc=2, ubp_av=0x7fffffffe498, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe488) at libc-start.c:226 #11 0x000000000041b931 in _start () (gdb) p cidx $1 = 1 (gdb) p cstart $2 = 227533755 (gdb) p cbytes $3 = 168 (gdb) p openFiles_ $4 = {<std::_Vector_base<std::basic_ifstream<char, std::char_traits<char> >*, std::allocator<std::basic_ifstream<char, std::char_traits<char> >*> >> = { _M_impl = {<std::allocator<std::basic_ifstream<char, std::char_traits<char> >*>> = {<__gnu_cxx::new_allocator<std::basic_ifstream<char, std::char_traits<char> >*>> = {<No data fields>}, <No data fields>}, _M_start = 0xd845b0, _M_finish = 0xd845c0, _M_end_of_storage = 0xd845c0}}, <No data fields>} (gdb) p fileSizes_ $5 = {<std::_Vector_base<unsigned int, std::allocator<unsigned int> >> = { _M_impl = {<std::allocator<unsigned int>> = {<__gnu_cxx::new_allocator<unsigned int>> = {<No data fields>}, <No data fields>}, _M_start = 0x10a7a20, _M_finish = 0x10a7a28, _M_end_of_storage = 0x10a7a28}}, <No data fields>} (gdb) I'll leave gdb running, so if there's anything else you want me to type at the gdb prompt, let me know...
|
|
|
Here's another lucky martingale escape which accounts for the last spike up and back down on the blue line:
Make sure to chronically the flipside too. The failures, though sad, are also entertaining... and can serve as a cautionary tale for others. Here's a cautionary tale if ever I saw one: 2012-07-28 00:37:45 <24000 Bet: 4.20000000 Outcome: LOSE Payment: 0.02050000 Profit: -4.1795 Cumulative: -4.1795 2012-07-28 00:37:54 <24000 Bet: 6.80000000 Outcome: LOSE Payment: 0.03350000 Profit: -6.7665 Cumulative: -10.946 2012-07-28 00:38:06 <24000 Bet: 10.80000000 Outcome: LOSE Payment: 0.05350000 Profit: -10.7465 Cumulative: -21.6925 2012-07-28 00:38:27 <24000 Bet: 17.20000000 Outcome: LOSE Payment: 0.08550000 Profit: -17.1145 Cumulative: -38.807 2012-07-28 00:39:01 <24000 Bet: 27.40000000 Outcome: LOSE Payment: 0.13650000 Profit: -27.2635 Cumulative: -66.0705 2012-07-28 00:39:18 <24000 Bet: 43.80000000 Outcome: LOSE Payment: 0.21850000 Profit: -43.5815 Cumulative: -109.652 2012-07-28 00:39:40 <24000 Bet: 70.00000000 Outcome: LOSE Payment: 0.34950000 Profit: -69.6505 Cumulative: -179.3025 2012-07-28 00:40:02 <24000 Bet: 112.00000000 Outcome: LOSE Payment: 0.55950000 Profit: -111.4405 Cumulative: -290.743
2012-07-28 00:40:49 <24000 Bet: 4.20000000 Outcome: LOSE Payment: 0.02050000 Profit: -4.1795 Cumulative: -294.9225 2012-07-28 00:41:04 <24000 Bet: 6.80000000 Outcome: WIN Payment: 18.15638853 Profit: 11.35638853 Cumulative: -283.56611147
2012-07-28 00:41:25 <24000 Bet: 4.20000000 Outcome: WIN Payment: 11.21404880 Profit: 7.0140488 Cumulative: -276.55206267
2012-07-28 00:42:29 <24000 Bet: 4.20000000 Outcome: LOSE Payment: 0.02050000 Profit: -4.1795 Cumulative: -280.73156267 2012-07-28 00:43:10 <24000 Bet: 6.80000000 Outcome: LOSE Payment: 0.03350000 Profit: -6.7665 Cumulative: -287.49806267 2012-07-28 00:43:39 <24000 Bet: 10.80000000 Outcome: LOSE Payment: 0.05350000 Profit: -10.7465 Cumulative: -298.24456267 2012-07-28 00:44:19 <24000 Bet: 17.20000000 Outcome: LOSE Payment: 0.08550000 Profit: -17.1145 Cumulative: -315.35906267 2012-07-28 00:48:23 <24000 Bet: 27.40000000 Outcome: LOSE Payment: 0.13650000 Profit: -27.2635 Cumulative: -342.62256267 2012-07-28 00:50:52 <24000 Bet: 43.80000000 Outcome: LOSE Payment: 0.21850000 Profit: -43.5815 Cumulative: -386.20406267 2012-07-28 00:51:23 <24000 Bet: 70.00000000 Outcome: LOSE Payment: 0.34950000 Profit: -69.6505 Cumulative: -455.85456267
|
|
|
1) Patrick - you seem to be a guy with a good heart, i.e. not looking to scam people - but you are just too stupid to understand what is going on here. You don't bring people over to your point of view by calling them stupid. Incidentally, did you know that Patrick runs his own fund which currently pays 1.5% per week? https://bitcointalk.org/index.php?topic=61262.0Does that qualify him for your list of scammers? 3) anyone want to explain to me why the BS&T thread is locked? can Pirate lock that thread at his whim? who authorizes that? who runs bitcointalk.org? (sorry for newbie Q's, please answer me or PM me if you feel foolish answering publicly) Anyone can lock any thread that they themselves started. I think there's a link in the lower left corner of the page; you should see it on this thread. There's no way for a thread's starter to control what other people say in their thread other than by locking the thread. Maybe it's possible to ask moderators to delete individual posts, but that's time consuming, and I don't know how effective it is. Pirate locked his thread when the "is it or isn't it a ponzi" posts swamped all the other posts in the thread.
|
|
|
2: This address was first charged some time in late January 2012. BS&T was set up in early November 2011 afaik (check here: https://bitcointalk.org/index.php?topic=50822.0). It is therefore in the correct time frame in order to belong to pirate's BS&T operation. If pirate is somehow putting his lenders' coins to work to make 10% per week, they wouldn't be sitting in a single address for months at a time If pirate is running a ponzi scheme, he wouldn't have this many coins since he has to pay out interest every week without any means of generating income other than from new deposits. He 'should' have around this many coins, but by definition ponzi schemes don't have as much as they 'should'. These two 'facts' suggest to me that these aren't pirate's coins.
|
|
|
I've never been into gambling, but after trying the php bot mentioned above (just because I think automating any task increase the coolness factor to over 9000) and winning more than 100% of the original value.. the temptation is so strong! I'm not sure what's so special about SD... maybe the fast speed ensure the dope of adrenalin every few seconds * Almost instant feedback * Provably fair * Low house edge A winning combination.
|
|
|
I'll see if I can count them: >>> -16259 - 11 +1222 +37031 -11272 10711 What's that? The last loss is so big it doesn't fit in the box? >>> -16259 - 11 +1222 +37031 -112725 -90742 Wow. That's a lot of money to be losing at poker!
|
|
|
|