1 2012-05-05 00:05:23 <gmaxwell> luke-jr: was that the only pass through the loop there? if not what was the dpriority value on the last iteration?
  2 2012-05-05 00:07:20 <gmaxwell> luke-jr: got it
  3 2012-05-05 00:08:22 <gmaxwell> oh darn nope.
  4 2012-05-05 00:10:05 <luke-jr> gmaxwell: it's not vanilla code
  5 2012-05-05 00:10:14 <gmaxwell> oh hey, I have a deadlocked node
  6 2012-05-05 00:10:16 <luke-jr> well, there are some bugs in the debug printing code
  7 2012-05-05 00:10:34 <luke-jr> but the problem I was really facing turned out to be my factor-in-fees code
  8 2012-05-05 00:10:57 <luke-jr> & I thoguht
  9 2012-05-05 00:11:27 <gmaxwell> woot! I have an addrman crash
 10 2012-05-05 00:11:29 <gmaxwell> in valgrind!
 11 2012-05-05 00:12:25 <luke-jr> gmaxwell: you are my hero!
 12 2012-05-05 00:13:26 <sipa> gmaxwell: o/
 13 2012-05-05 00:14:16 <sipa> tell me where!
 14 2012-05-05 00:14:40 <luke-jr> yeah, lart sipa for writing buggy code :P
 15 2012-05-05 00:15:20 <gmaxwell> sipa: http://pastebin.com/XssbAmLK
 16 2012-05-05 00:15:29 <gmaxwell> It managed to crash valgrind at the same time. 0_o
 17 2012-05-05 00:16:22 <gmaxwell> perhaps because the pty it was outputting to was blocked or something.
 18 2012-05-05 00:18:10 <gribble> New news from bitcoinrss: sipa opened pull request 1196 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1196>
 19 2012-05-05 00:22:39 <gmaxwell> sipa: http://people.xiph.org/~greg/tail.log.gz  < end of the log before it died.. I don't think there is anything useful there.. but I'm late for a movie, will bbiafhours
 20 2012-05-05 00:22:57 <sipa> gmaxwell: you don't happen to be able to gdb the process or have a core dump?
 21 2012-05-05 00:23:33 <gmaxwell> sipa: no because valgrind died and I didn't have db attach enabled.
 22 2012-05-05 00:24:50 <gmaxwell> I restarted it with dbattach enabled..
 23 2012-05-05 00:24:57 <gmaxwell> oh but it seems my addr.dat is corrupted.
 24 2012-05-05 00:25:09 <sipa> like always...
 25 2012-05-05 00:25:33 <sipa> bdb corrupted?
 26 2012-05-05 00:26:07 <gmaxwell> ************************
 27 2012-05-05 00:26:08 <gmaxwell> EXCEPTION: NSt8ios_base7failureE
 28 2012-05-05 00:26:39 <sipa> care to send me the addr.dat file?
 29 2012-05-05 00:28:05 <gmaxwell> http://people.xiph.org/~greg/addrbad.dat
 30 2012-05-05 00:30:00 <sipa> thanks; will have a look tomorrow
 31 2012-05-05 00:43:52 <gribble> New news from bitcoinrss: luke-jr opened pull request 1197 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1197>
 32 2012-05-05 01:41:33 <jgarzik> sipa: just stumbled upon how you save addrman addresses.... ewww, what a hack :)
 33 2012-05-05 01:42:04 <jgarzik> sipa: just store it directly in GetDataDir() / "addrman.dat", and ignore bdb altogether
 34 2012-05-05 01:42:39 <sipa> jgarzik: yes, that should change
 35 2012-05-05 01:42:41 <jgarzik> sipa: delete CAddrDB and addr.dat-related code.  we don't care enough about addresses to keep that code around.
 36 2012-05-05 01:43:10 <sipa> especially now that upgrading from addr.dat seems problematic
 37 2012-05-05 01:43:19 <jgarzik> sipa: addrman does its own serialize -and- already stores the data in its entirety on each write... that is much better served as a separate file outside bdb
 38 2012-05-05 01:44:04 <sipa> never-cleared interprocess locks that appear to cause deadlocks when deleting the relevant entries
 39 2012-05-05 01:44:48 <jgarzik> hum.  whose locks, I wonder... bdb's or bitcoin's?
 40 2012-05-05 01:45:22 <sipa> it was never intended to remain in addr.dat, but it was useful for upgrading
 41 2012-05-05 01:45:41 <sipa> bdb's of course, bitcoin has no interprocess locks
 42 2012-05-05 01:45:58 <jgarzik> bool CAddrDB::LoadAddresses()
 43 2012-05-05 01:46:14 <sipa> especially none that get f*cking saved in a file
 44 2012-05-05 01:47:03 <jgarzik> sipa: I'm bored enough that I might poke at addrman.dat tonight, if you've no objections
 45 2012-05-05 01:47:18 <sipa> feel free
 46 2012-05-05 01:47:46 <jgarzik> sipa: think there is any value in gzip compression?
 47 2012-05-05 01:47:46 <sipa> i want to get rid of bdb for everything except blkindex
 48 2012-05-05 01:48:11 <jgarzik> sipa: boost has a spiffy zlib filter for streams
 49 2012-05-05 01:48:11 <sipa> it would certainly help
 50 2012-05-05 01:48:24 <sipa> but the file is already limited in size
 51 2012-05-05 01:48:52 <sipa> not sure if people care about 3 MiB instead of 4
 52 2012-05-05 01:50:14 <sipa> i'd rename the file
 53 2012-05-05 01:50:41 <sipa> call it ipaddr.dat maybe, as addr is ambiguous in bitcoin's context
 54 2012-05-05 01:50:48 <jgarzik> sipa: sure
 55 2012-05-05 01:51:44 <sipa> wallets will be more fun to debdb
 56 2012-05-05 03:10:34 <paulo_> what ECDSA do you use?
 57 2012-05-05 03:10:39 <paulo_> secpack something?
 58 2012-05-05 03:11:50 <riush> secp256k1
 59 2012-05-05 03:12:05 <paulo_> thanks
 60 2012-05-05 05:02:49 <dddddddddd0> Hi, I'm trying to compile bitcoind, but I keep getting this: "/usr/bin/ld: cannot find -ldb_cxx" when I try compiling. I do have berkeley db installed, so I'm not sure why I get this message
 61 2012-05-05 05:06:27 <weex> dddddddddd0: running ldconfig might help
 62 2012-05-05 05:07:13 <dddddddddd0> tried that, didn't change the error
 63 2012-05-05 05:10:54 <gmaxwell> you need db++ (the c++ wrapper on bdb, not just bdb itself)
 64 2012-05-05 05:12:42 <dddddddddd0> So under ubuntu, this would be libdb4.8++-dev?
 65 2012-05-05 05:13:16 <gmaxwell> Yes... also, you might enjoy reading the file doc/build-unix.txt
 66 2012-05-05 05:13:17 <dddddddddd0> I can't find that package for my distro :(
 67 2012-05-05 05:13:44 <dddddddddd0> I only find libdb4.8-dev
 68 2012-05-05 05:14:09 <dddddddddd0> That's actually what I'm using
 69 2012-05-05 05:14:22 <gmaxwell> What distro are you using?
 70 2012-05-05 05:14:41 <dddddddddd0> ubuntu 12.04, just set up the vm like 2 hours ago to compile bitcoind
 71 2012-05-05 05:17:22 <gmaxwell> dddddddddd0: the latest ubuntu has removed libdb4.8++ and only ships libdb5.1  (libdb++), bitcoin can be built against that but it's not (as) well tested. And the files it writes can't be read by earlier versions.
 72 2012-05-05 05:18:16 <dddddddddd0> how unlikely would it be that libdb4.8++ for "lucid" would work on 12.04?
 73 2012-05-05 05:18:55 <gmaxwell> no idea. though you can just use the bitcoin binaries which are compiled statically and work on whatever.
 74 2012-05-05 05:24:49 <BlueMatt> gmaxwell: whats up with 0.6.1, its tagged, so I guess builds are going?
 75 2012-05-05 05:24:58 <wumpus> it works well with libdb5.1... the only problem is that you can never use the db with an older libdb version again
 76 2012-05-05 05:25:50 <wumpus> BlueMatt: yes
 77 2012-05-05 05:25:56 <BlueMatt> fun...
 78 2012-05-05 05:26:43 <gmaxwell> BlueMatt: the files are up.
 79 2012-05-05 05:26:52 <gmaxwell> BlueMatt: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.1/
 80 2012-05-05 05:27:03 <BlueMatt> oh, even bins...
 81 2012-05-05 05:27:15 <BlueMatt> arg...well now I need to go whip up an ubuntu vm to do the ppa...
 82 2012-05-05 05:27:16 <dddddddddd0> unpacked the .deb and manually copied the files over
 83 2012-05-05 05:27:19 <dddddddddd0> it worked
 84 2012-05-05 05:40:04 <jgarzik> sipa: there ya go
 85 2012-05-05 05:40:08 <jgarzik> sipa: compile-tested only
 86 2012-05-05 05:42:59 <gribble> New news from bitcoinrss: jgarzik opened pull request 1198 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1198>
 87 2012-05-05 06:03:44 <gribble> New news from bitcoinrss: laanwj opened pull request 1199 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1199>
 88 2012-05-05 06:09:05 <gribble> New news from bitcoinrss: TheBlueMatt reopened pull request 771 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/771>
 89 2012-05-05 07:30:12 <gribble> New news from bitcoinrss: laanwj opened pull request 1200 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1200>
 90 2012-05-05 07:35:14 <gribble> New news from bitcoinrss: Diapolo opened pull request 1201 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1201>
 91 2012-05-05 07:40:40 <gribble> New news from bitcoinrss: Diapolo opened pull request 1202 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1202>
 92 2012-05-05 07:45:49 <gribble> New news from bitcoinrss: Diapolo opened pull request 1203 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1203>
 93 2012-05-05 07:51:49 <Keefe> why would bitcoin-qt.exe be suddenly using 50% cpu, all in advapi32.dll?
 94 2012-05-05 07:52:15 <Keefe> cpu is dual-core, so 100%
 95 2012-05-05 07:52:36 <Keefe> bug? someone trying to brute force my pwd?
 96 2012-05-05 07:54:28 <Keefe> i'm just going by what Sysinternals Process Explorer says
 97 2012-05-05 08:04:18 <sturles> Latest version?  Is it mining?
 98 2012-05-05 08:33:10 <wumpus> Keefe: what version? is this during initial block dl?
 99 2012-05-05 08:56:32 <Keefe> sturles, wumpus: was not mining with it. not downloading blocks as far as i could tell. was using 100% cpu for just a few minutes then back to normal
100 2012-05-05 08:56:46 <Keefe> 0.5.3.1
101 2012-05-05 08:57:11 <Keefe> it got my attention because my laptop fan came on
102 2012-05-05 08:57:41 <Keefe> and it had been running for a long time before without excessing cpu use
103 2012-05-05 08:57:49 <Keefe> excessive*
104 2012-05-05 11:29:36 <gribble> New news from bitcoinrss: Diapolo opened pull request 1204 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1204>
105 2012-05-05 12:12:53 <luke-jr> gmaxwell: http://blockchain.info/block/0000000000000790e48fa1800a77a13fc7534f64ee2d70dfce1eb17533f9070a
106 2012-05-05 12:58:57 <sipa> gmaxwell: that addrbad.dat is unusable without its environment of course
107 2012-05-05 12:59:09 <sipa> can you db5.1_dump it, maybe?
108 2012-05-05 13:47:38 <gribble> New news from bitcoinrss: laanwj opened pull request 1205 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1205>
109 2012-05-05 14:33:46 <gribble> New news from bitcoinrss: Diapolo opened pull request 1206 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1206>
110 2012-05-05 14:54:02 <gribble> New news from bitcoinrss: luke-jr opened pull request 35 on bitcoin/bitcoin.org <https://github.com/bitcoin/bitcoin.org/pull/35>
111 2012-05-05 15:49:36 <gmaxwell> Anyone know any reason not to push the website to 0.6.1?
112 2012-05-05 15:49:59 <gmaxwell> Has someone gitian seconded the 0.6.1 builds?
113 2012-05-05 15:50:10 <sipa> i've built them, let me verify
114 2012-05-05 15:50:20 <etotheipi_> because not 100% of the internet has agreed it's perfect.  Let's keep waiting
115 2012-05-05 15:50:47 <luke-jr> gmaxwell: I built 0.6.1 windows
116 2012-05-05 15:50:54 <gmaxwell> luke-jr: does it match?
117 2012-05-05 15:51:03 <luke-jr> gmaxwell: I don't know, Gavin didn't push his :p
118 2012-05-05 15:51:30 <sipa> mine match both
119 2012-05-05 15:52:08 <gmaxwell> Merged.
120 2012-05-05 15:52:08 <sipa> pushed
121 2012-05-05 15:52:11 <luke-jr> install from SF matches
122 2012-05-05 15:52:59 <luke-jr> gmaxwell: P{M
123 2012-05-05 15:54:05 <luke-jr> gmaxwell: kicked
124 2012-05-05 15:54:06 <luke-jr> http://eu1.bitcoincharts.com/bitcoin.org/cgi-bin/update.sh
125 2012-05-05 15:54:32 <gmaxwell> I already had.
126 2012-05-05 15:54:44 <gmaxwell> and it's up now.
127 2012-05-05 15:59:17 <sipa> gmaxwell: that addrbad.dat is unusable without its environment of course; can you do a db5.1_dump ?
128 2012-05-05 16:01:30 <gmaxwell> sipa: unfortunately I have since deleted the addr.dat there and restarted that node. :-/  (hoping to reproduce again with dbattach set
129 2012-05-05 16:01:46 <sipa> ok
130 2012-05-05 16:02:04 <sipa> i've already found a bug in addrman by the way, but not one that can have caused the crash
131 2012-05-05 16:02:50 <gmaxwell> I'm wondering if we're managing to get a non-threadsafe malloc or something. It looks like two threads could have been in malloc when the crash happened.
132 2012-05-05 16:03:03 <gmaxwell> (well right before it happened)
133 2012-05-05 16:04:46 <sipa> all right; just got it to reproduce the bug
134 2012-05-05 16:05:51 <sipa> well, a bug
135 2012-05-05 16:09:57 <gmaxwell> I was wondering if I should hack in a rapid addraddr loop to try to trigger it.
136 2012-05-05 16:10:18 <sipa> gmaxwell: i made a branch that set pfrom->fDisconnect when receiving an addr message
137 2012-05-05 16:10:31 <sipa> but i'm close
138 2012-05-05 16:12:52 <sipa> gmaxwell: comment the "// first check whether there is place to just add it" block out in MakeTried, and change the int nUBucket initialization to nOrigin, in that function
139 2012-05-05 16:13:09 <sipa> if i'm right, that will trigger the bug almost immediately
140 2012-05-05 16:29:23 <gmaxwell> sipa: ==30940== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- n
141 2012-05-05 16:29:24 <gmaxwell> ==30940== Thread 11:
142 2012-05-05 16:31:43 <gmaxwell> So indeed...
143 2012-05-05 16:51:06 <sipa> i know exactly which code path produces the error, but i fail to understand why the code can cause the problem
144 2012-05-05 16:52:22 <gmaxwell> I don't see the problem. :-/
145 2012-05-05 16:52:33 <gmaxwell> I assume you can reproduce it now?
146 2012-05-05 16:52:53 <sipa> yes
147 2012-05-05 16:53:52 <sipa> gmaxwell: the valgrind complaint can happen significantly later than the actual corruption
148 2012-05-05 16:56:13 <gmaxwell> sipa: not unusual.
149 2012-05-05 16:57:28 <sipa> gmaxwell: got it
150 2012-05-05 16:57:33 <sipa> shameful :s
151 2012-05-05 16:58:19 <sipa> SelectTried returns the identifier inside vvTried[nKBucket] that should be removed
152 2012-05-05 16:58:43 <sipa> but its return value is used as the index in that vector, instead of the value therein
153 2012-05-05 16:59:55 <gmaxwell> crap that a stronger type system would save us from.
154 2012-05-05 17:00:11 <graingert> gmaxwell: remove the call to /dev/random
155 2012-05-05 17:00:19 <graingert> just use the PID as random source
156 2012-05-05 17:00:45 <gmaxwell> graingert: er, what are you responding to?
157 2012-05-05 17:01:00 <graingert> the valgrind complaint
158 2012-05-05 17:01:17 <graingert> whenever you have a piece of security software that fails valgrind
159 2012-05-05 17:01:23 <gmaxwell> No relation.
160 2012-05-05 17:01:25 <graingert> you remove any calls to /dev/random
161 2012-05-05 17:01:39 <gmaxwell> Calls to dev/random do not make valgrind fail.
162 2012-05-05 17:01:57 <graingert> well that's what they fixed in debian
163 2012-05-05 17:02:00 <graingert> SSL
164 2012-05-05 17:02:09 <sipa> "fixed"
165 2012-05-05 17:02:22 <gmaxwell> graingert: You substantially misunderstand that.
166 2012-05-05 17:02:30 <graingert> I see
167 2012-05-05 17:02:49 <graingert> that sucks because I did a course on it :(
168 2012-05-05 17:02:54 <sipa> seems the bug is fixed
169 2012-05-05 17:03:02 <graingert> courses never quite get it right
170 2012-05-05 17:03:50 <gmaxwell> graingert: Openssl was written by idiots who think it's grand idea to mix uninitilized memory (which is almost always zeros) into the random pool. This is formally undefined behavior and the compiler is allowed to insert system("rm -rf /") in place of it. (though fortunately in this case it does nothing weird)
171 2012-05-05 17:04:12 <gmaxwell> graingert: that, however, makes valgrind complain that all the produced random values are tainted. (because they are)
172 2012-05-05 17:04:36 <graingert> ah
173 2012-05-05 17:04:42 <graingert> that was never mentioned
174 2012-05-05 17:04:46 <graingert> only how to sploit it
175 2012-05-05 17:04:55 <graingert> and how to search for those keys
176 2012-05-05 17:05:15 <gmaxwell> graingert: when some genius debian package maintainer noticed this he offered up a patch to fix it. But his fix was too agressive and removed the real randomness too.  Oddly openssl already had a define for turning off the use of uninitilized memory.
177 2012-05-05 17:05:40 <gmaxwell> graingert: after the openssl people did not protest his patch, he applied it in debian. The rest is history.
178 2012-05-05 17:06:26 <gmaxwell> My openssl libraries have the define set its basically impossible to use valgrind on bitcoin otherwise.
179 2012-05-05 17:06:46 <sipa> gmaxwell: strange, i don't get any openssl complaints from valgrind here
180 2012-05-05 17:06:57 <sipa> maybe ubuntu sets that define by default?
181 2012-05-05 17:07:15 <gmaxwell> sipa: they may, though the complaints you get are never on openssl ... they're on random places where openssl randomness is used in the code.
182 2012-05-05 17:07:58 <sipa> gmaxwell: the only valgrind complaint i ever see is BDB
183 2012-05-05 17:07:59 <gmaxwell> graingert: What sipa was pointing out was that valgrind often reports much later than when the evil happened, this is by design: in order to suppress false alarms e.g. when uninitilized struct padding is copied, it only alarms when the tainted data would be output or would change the program flow.
184 2012-05-05 17:08:18 <gmaxwell> sipa: yea, then ubuntu must be compiling with -DPURIFY. Good for them.
185 2012-05-05 17:08:31 <graingert> cool
186 2012-05-05 17:09:00 <sipa> anyway; addrman problem fixed; it would only occur to people where a new address is moved to the tried set, to a bucket that was already full
187 2012-05-05 17:09:18 <gmaxwell> So. e.g.   foo=unintilized; bar=foo+1; if(bar>5){print..}  ... would valgrind on the if but not before.
188 2012-05-05 17:09:49 <sipa> requires having connected to a few thousand nodes before the chance for that is reasonable
189 2012-05-05 17:10:28 <gmaxwell> sipa: I'm thinking we should just cut a 0.6.2rc1 on monday, with that and the stuck chain fix, and whatever little bits we pick up before then.
190 2012-05-05 17:12:10 <sipa> sounds good
191 2012-05-05 17:28:03 <luke-jr> devrandom: ping
192 2012-05-05 17:28:05 <luke-jr> ./bin/gbuild:25:in `sanitize_path': unsanitary string in https://git.gitorious.org/+bitcoin-stable-developers/bitcoin/bitcoind-stable.git (RuntimeError)
193 2012-05-05 17:29:01 <sipa> i suppose it cannot deal with + characters in URLs?
194 2012-05-05 17:29:17 <gmaxwell> I hate c++
195 2012-05-05 17:29:37 <gmaxwell> I pulled 1160 locally for testing.. compiled it.. and it fking OOMed me.
196 2012-05-05 17:29:44 <sipa> gmaxwell: come on... what better way to shoot yourself in the foot do you know?
197 2012-05-05 17:30:56 <gmaxwell> otoh, oomkiller picked the right victim for once
198 2012-05-05 17:30:59 <gmaxwell> [126541.365890] Killed process 28313 (cc1plus) total-vm:608436kB, anon-rss:470904kB, file-rss:276kB
199 2012-05-05 17:31:19 <gmaxwell> oh well, at least I noticed that swap got disabled on my laptop.
200 2012-05-05 17:41:48 <gribble> New news from bitcoinrss: sipa opened pull request 1207 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1207>
201 2012-05-05 17:42:06 <luke-jr> wtf, I go to make a video of my problem, and it works -.-
202 2012-05-05 17:42:28 <sipa> luke-jr: ^ please test :)
203 2012-05-05 17:43:06 <luke-jr> sipa: I can't reproduce it easily anymore :<
204 2012-05-05 17:43:44 <gmaxwell> Can someone give me a mature addrman addr.dat? (from a cleanly shutdown node please)
205 2012-05-05 17:43:48 <gmaxwell> that should speed up reproducing.
206 2012-05-05 17:44:07 <gmaxwell> oh I may have one...
207 2012-05-05 17:44:32 <gmaxwell> K. I do.
208 2012-05-05 17:45:05 <sipa> -    if (vTried.size() < ADDRMAN_TRIED_BUCKET_SIZE)
209 2012-05-05 17:45:20 <sipa> luke-jr, gmaxwell: ^ that will speed up reproducing a lot
210 2012-05-05 17:46:10 <gmaxwell> how about < 2 so all the code still gets tested?
211 2012-05-05 17:47:14 <sipa> all code still gets tested, the most common case is 0 if you start from an empty addr.dat
212 2012-05-05 17:47:36 <sipa> (i'm convinced the problem caused by the line change in the old code, is fixed now; but the question remains whether the bug caused by it is the same as the one seen before)
213 2012-05-05 17:47:56 <sipa> everything points to it, including the unparsable addr.dat file afterwards
214 2012-05-05 17:49:08 <gmaxwell> Okay, running with that change.. also started from a three week old addr.dat (well, better than nothing)
215 2012-05-05 17:50:24 <sipa> gmaxwell: #1160 OOMed on you, and you merged it?
216 2012-05-05 17:50:51 <sipa> ok, shouldn't be caused by that patch
217 2012-05-05 17:51:39 <gmaxwell> sipa: the _compiler_ oomed me, because I make cleaned.. before testing the patch. It was unrelated to the patch. I was just whining at make -j2 needing 1200 MB ram to compile bitcoin.
218 2012-05-05 17:53:45 <sipa> gmaxwell: not sure you read my comment some time ago, but using -flto on the linux 64-bit bitcoin-qt build shrunk the stripped binary size from 4185480 to 2926280
219 2012-05-05 17:53:49 <luke-jr> gmaxwell: http://blockchain.info/block/0000000000000775f57768217191247b1f78ed9d8fea58038d13c0ec8ace7f97
220 2012-05-05 17:54:18 <gmaxwell> sipa: yea, I did. And probably also makes the code faster at runtime.
221 2012-05-05 17:54:37 <gmaxwell> luke-jr: what am I supposted to notice here?
222 2012-05-05 17:54:48 <luke-jr> gmaxwell: Number of transactions ;)
223 2012-05-05 17:55:04 <gmaxwell> Ah.
224 2012-05-05 17:55:10 <gmaxwell> Okay. Indeed.
225 2012-05-05 17:55:20 <gribble> 178786
226 2012-05-05 17:55:20 <sipa> ;;bc,blocks
227 2012-05-05 17:55:45 <luke-jr> why does 71 MB take so long to upload?
228 2012-05-05 17:56:35 <sipa> gmaxwell: i actually have some code here that performs significantly slower under -flto (like 10%)
229 2012-05-05 17:56:57 <sipa> (not bitcoin related)
230 2012-05-05 17:57:14 <gmaxwell> Intresting, it's usually a pretty good speedup (for a couple of reasons, but mostly because it helps inlining)
231 2012-05-05 17:58:44 <gmaxwell> I have some production codec code that gains something like 15% with LTO alone. (O3,lto,-fno-math-errno is something like 25% over -O2 on that codebase)
232 2012-05-05 17:59:27 <sipa> probably an extreme example; it's a few .cpp files with utility routines, but the actual heave part is in one .o file, and created from very templated code
233 2012-05-05 18:00:14 <gmaxwell> The firefox folks suggest a param tweak that makes the inliner a bit less agressive and seems to fix some cases where excessive inlining slows it down.
234 2012-05-05 18:00:54 <luke-jr> is LTO ever dangerous?
235 2012-05-05 18:01:11 <sipa> you mean whether it is sufficiently tested?
236 2012-05-05 18:01:14 <gmaxwell> If there is compiler bugs... of course.
237 2012-05-05 18:01:19 <luke-jr> I mean, will it break code :p
238 2012-05-05 18:01:28 <luke-jr> if I enable it for everythign on my system
239 2012-05-05 18:01:52 <sipa> ah gentoo people ;)
240 2012-05-05 18:01:55 <luke-jr> actually, I think I use -O0 these days
241 2012-05-05 18:02:00 <sipa> :o
242 2012-05-05 18:02:06 <gmaxwell> No, absent a buggy compiler it shouldn't break anything.  It's not that widely used yet, so it's had less testing. Also its less useful in older gcc.
243 2012-05-05 18:02:08 <luke-jr> CFLAGS="-O2 -march=core2 -pipe -ggdb -O0"
244 2012-05-05 18:02:14 <gmaxwell> 0_o
245 2012-05-05 18:02:18 <luke-jr> <.<
246 2012-05-05 18:02:26 <luke-jr> I like debugging?
247 2012-05-05 18:02:37 <gmaxwell> yea, but you don't like useful warnings?
248 2012-05-05 18:02:37 <luke-jr> CPUs are plenty fast enough anyway
249 2012-05-05 18:02:54 <luke-jr> gmaxwell: well, this is for my system stuff :p
250 2012-05-05 18:03:06 <luke-jr> when I break out the compiler, I'll usually use -Wall
251 2012-05-05 18:03:28 <gmaxwell> no no, turning down optimization actually removes some warnings.
252 2012-05-05 18:03:39 <sipa> i thought all gentoo people compiled using "-O17 -fskip-checks -femit-broken-code"
253 2012-05-05 18:03:56 <gmaxwell> But egads, it's not hard to find code thats 5x slower with -O0 vs O2.
254 2012-05-05 18:04:14 <sipa> (ok kidding, i used to run gentoo too, and used -O2 afaik)
255 2012-05-05 18:04:34 <gmaxwell> --param spoilersize=extra_large -funroll_universe
256 2012-05-05 18:05:11 <luke-jr> gmaxwell: I find -O2 produces useless backtraces sometimes
257 2012-05-05 18:06:33 <sipa> at least use -O1 the, to get the obviously naive things out of the way
258 2012-05-05 18:09:37 <luke-jr> -O1 doesn't make backtraces useless? :p
259 2012-05-05 18:10:35 <gmaxwell> O2 usually shouldn't either
260 2012-05-05 18:11:10 <gmaxwell> luke-jr: where is db++ in gentoo?
261 2012-05-05 18:11:51 <luke-jr> sys-libs/db USE=cxx
262 2012-05-05 18:12:07 <luke-jr> gmaxwell: of course, you can just emerge net-p2p/bitcoind to get all the deps&
263 2012-05-05 18:14:56 <luke-jr> http://www.youtube.com/watch?v=fuEylMLpfOw
264 2012-05-05 18:19:45 <luke-jr> hmm, only lasts 13 minutes from the top
265 2012-05-05 18:21:00 <gmaxwell> make it out of metal (to lower friction) and increase the weight.
266 2012-05-05 18:21:47 <luke-jr> gmaxwell: well, the problem right now is the weight hitting the floor too soon :p
267 2012-05-05 18:38:31 <BlueMatt> whats up with 0.6.1, bins are up, but no release yet?
268 2012-05-05 18:38:42 <luke-jr> BlueMatt: no? what's missing for the release?
269 2012-05-05 18:38:58 <BlueMatt> putting it on bitcoin.org?
270 2012-05-05 18:39:10 <luke-jr> it's on there
271 2012-05-05 18:39:35 <BlueMatt> oh...hmm...chrome didnt wanna load the page...yea oops
272 2012-05-05 18:47:44 <sipa> who can put it on the forum?
273 2012-05-05 18:48:14 <BlueMatt> I think gavin always does...may seem weird if its not signed from gavin...
274 2012-05-05 18:48:37 <luke-jr> I concur.
275 2012-05-05 18:48:53 <luke-jr> I could throw it in the thread I made for 0.4.6 and 0.5.5, but people who look for Gavin might miss it
276 2012-05-05 18:51:25 <gmaxwell> No harm in soft pedaling the promotion if we're going to cut a 0.6.2 in a few days (for the sync and addrman fixes)
277 2012-05-05 18:52:13 <BlueMatt> oh, yay, no 0.7 merge window yet (again)...
278 2012-05-05 18:52:56 <luke-jr> master already has commits that would interfere with a 0.6.2 fwiw
279 2012-05-05 18:53:06 <luke-jr> other than coming out of a stable 0.6.x branch
280 2012-05-05 18:53:17 <luke-jr> I guess that's my job <.<
281 2012-05-05 18:53:28 <gmaxwell> luke-jr: such as?
282 2012-05-05 18:53:56 <luke-jr> gmaxwell: Diapolo/fix#945 at least requires adjusting every translation
283 2012-05-05 18:54:16 <luke-jr> and new strings from some new features
284 2012-05-05 18:54:49 <luke-jr> Diapolo/signmessage_clear Diapolo/qrcodedialog Diapolo/messagepage
285 2012-05-05 18:55:09 <luke-jr> I guess it doesn't interfere directly, but it would delay a release until they're translated
286 2012-05-05 18:55:33 <luke-jr> I guess as long as the sync/addrman fixes didn't expose any security issue, that's ok
287 2012-05-05 18:56:09 <gmaxwell> Well, I don't really want to have a long delay here as I want to start pulling for 0.7.0 about a week ago.
288 2012-05-05 18:57:09 <luke-jr> yeah
289 2012-05-05 18:57:53 <Blitzboom> what features are coming up for 0.7?
290 2012-05-05 18:57:59 <luke-jr> I'll just plan to backport and roll 0.6.2 from a 0.6.x branch then
291 2012-05-05 18:58:03 <luke-jr> Blitzboom: see next-test
292 2012-05-05 18:58:22 <Blitzboom> luke-jr: link
293 2012-05-05 18:58:28 <luke-jr> https://bitcointalk.org/index.php?topic=78846.0
294 2012-05-05 18:58:37 <Blitzboom> thx
295 2012-05-05 18:59:02 <gmaxwell> Note that luke sometimes includes things in next-test that other folks are protesting. :)
296 2012-05-05 18:59:12 <Blitzboom> Support for Tonal Bitcoin units (GTBC, ??TBC, and TBC)
297 2012-05-05 18:59:14 <Blitzboom> lol
298 2012-05-05 18:59:59 <luke-jr> gmaxwell: those are red in the list ;)
299 2012-05-05 19:03:23 <gmaxwell> The totally naked ones are red, no? stuff like the logrotate on -HUP are being debated.
300 2012-05-05 19:04:03 <luke-jr> gmaxwell: I consider the "debate" on HUP dead; both "sides" agree something should be merged, just disagree on details
301 2012-05-05 19:08:20 <gmaxwell> sure sure, but whatever is in next-text may not be what makes it in.
302 2012-05-05 19:08:43 <gmaxwell> I'm not arguing with you, just making the point that next-text may not accurately reflect 0.7.0
303 2012-05-05 19:08:47 <gmaxwell> er test
304 2012-05-05 19:09:21 <luke-jr> well, it's next-test and not master for a reason :P
305 2012-05-05 19:09:42 <luke-jr> I think sipa's redone the torhs branch a few times already
306 2012-05-05 19:39:00 <sipa> luke-jr: many times
307 2012-05-05 20:10:01 <gavinandresen> i'm mostly not here....   but 0.6.1 was waiting for somebody else to gitian build and verify signatures
308 2012-05-05 20:10:56 <graingert> gavinandresen: heya gavin
309 2012-05-05 20:11:25 <gmaxwell> gavinandresen: yea, we got that.
310 2012-05-05 20:16:09 <sipa> there's no announcement on the forum yet, it seems
311 2012-05-05 20:26:09 <luke-jr> gavinandresen: you didn't push your own sigs for 0.6.1-win32
312 2012-05-05 20:27:24 <luke-jr> gavinandresen: master -> 0.6.2 or 0.7 needs a decision btw; there's already stuff merged in there that will cause delay for new translations, but otherwise it's "mostly ok" for 0.6.2
313 2012-05-05 20:27:44 <luke-jr> gavinandresen: 0.6.2 being with fixes for addrman crash and some other thing I'm not up to date on
314 2012-05-05 20:28:07 <luke-jr> gavinandresen: (if master shoots for 0.7, I can still do a 0.6.2 with those from a stable branch)
315 2012-05-05 20:28:13 <sipa> luke-jr: #1207 and #1196
316 2012-05-05 20:28:43 <luke-jr> sipa: ty
317 2012-05-05 20:38:29 <etotheipi_> could someone please send me some testnet coins?  I somehow ran out :(
318 2012-05-05 20:38:31 <etotheipi_> my5GEHDX9t9424Z2UR7hmcqLkYiy6bzNsC
319 2012-05-05 20:38:47 <luke-jr> how do you run out?
320 2012-05-05 20:39:16 <etotheipi_> well, by deleting/corrupting all the wallets that had any left
321 2012-05-05 20:56:34 <nanotube> etotheipi_: still need tnbtc?
322 2012-05-05 20:56:57 <etotheipi_> nanotube: I do!
323 2012-05-05 20:57:12 <nanotube> ok, i'll send you some, just gimme some time to bring up the client and sync up.
324 2012-05-05 20:58:13 <nanotube> bunch of empty blocks... zipping by fast. :)