[01:15:34] --- Russ has left: Disconnected
[05:24:03] --- sxw has become available
[05:35:55] --- sxw has left
[09:36:02] <kaduk@mit.edu/barnowl> Down to
7270cf5607e24..a180b0c5d8991a14
which includes
5ad1e6cb904b953fbb04603f3ce1466dcc38cd48 dir: Prototype and function name cleanup
0284e65f97861e888d95576f22a93cd681813c39 dir: Explicitly state buffer locations for data
[12:30:10] --- shadow@gmail.com/barnowl29570F23 has left
[12:30:20] --- shadow@gmail.com/barnowl29570F23 has become available
[12:30:51] --- Russ has become available
[12:45:07] --- kaduk@mit.edu/barnowl has left
[12:46:03] --- kaduk@mit.edu/barnowl has become available
[13:11:58] <kaduk@mit.edu/barnowl> Well, the blame seems to fall on
0284e65f97861e888d95576f22a93cd681813c39.
Too bad Simon's not in at the moment ...
[14:58:08] --- jaltman/FrogsLeap has left: Replaced by new connection
[14:58:10] --- jaltman/FrogsLeap has become available
[15:13:39] --- Simon Wilkinson has become available
[16:09:03] <Simon Wilkinson> Bah, I shouldn't write (and email) patches whilst distracted ...
[16:18:00] <kaduk@mit.edu/barnowl> Well, Marc's update build.
Firing off the test ...
[16:18:26] <Simon Wilkinson> Like I said, haven't tried it at all. But it is obviously wrong, so it shouldn't make things any worse.
[16:18:36] <Simon Wilkinson> Reason that Marc and I haven't seen this is that Linux has its own readdir code.
[16:31:29] <kaduk@mit.edu/barnowl> No luck, alas.
[16:36:12] <Simon Wilkinson> And that's with an up-to-date master?
[16:36:29] <kaduk@mit.edu/barnowl> Near enough to not matter.
[16:36:38] <kaduk@mit.edu/barnowl> (I could try with an old one, I suppose.)
[16:37:42] <Simon Wilkinson> You need 7829e7152361c38a22a7ba4c11e4f614e4392d60
[16:37:53] <Simon Wilkinson> (anything newer than that is fine, I think)
[16:39:00] <kaduk@mit.edu/barnowl> Oh, hrrm, apparently not as new as I thought.
[16:44:11] --- mdionne has become available
[16:46:06] <mdionne> i was going to ask earlier if you're sure you tested with that fix in.  that bug clearly leaks locked buffers - it increments the lock count then goes on to allocate and use a new entry
[17:00:05] <kaduk@mit.edu/barnowl> 9cf7a628c2ff178b2fa236d2c0a41ca9be315036 + that patch still barfs
[17:00:46] <kaduk@mit.edu/barnowl> (and leaks 256k more memory than 1.6)
[17:08:06] <mdionne> bummer, 9cf7a628 + 7829e715 + Simon's patch ?
[17:09:17] <kaduk@mit.edu/barnowl> Oh, whoops, I guess I don't have 9cf7 ...
[17:10:08] <kaduk@mit.edu/barnowl> Er, less' behavior is confusing.  Please hold.
[17:11:46] <kaduk@mit.edu/barnowl> I think I should have all three of those, but I'll give it another go
just to be sure.
[17:29:11] <kaduk@mit.edu/barnowl> Both 9cf7a628 and 7829e715 are in master; current master + Simon's
patch still fails.
[17:47:03] <mdionne> ok, must be something else in that patch then.  current master works OK on Linux for me, minus that 3.1 bug that I finally tracked down
[18:11:30] <kaduk@mit.edu/barnowl> Thoughts on going back to the offending commit versus staying on
master?
[18:48:32] --- mdionne has left