reconstruct caused mailboxes (skiplist) corruption?

[Bron Gondwana]

On Thu, Nov 11, 2010 at 02:24:47PM -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 11 Nov 2010, Paul Dekkers wrote:
> > Uhoh! And then I looked at mailboxes.db: It looks like part completely
> > rewritten, including the skiplist header, and the first line now said:
> > user.bla: System I/O error System I/O error
> 
> This is something that has plagued cyrus for a long time.  Can we find a
> way to actually keep tabs on our FDs so it cannot ever happen again,
> please?  I recall reports of crap showing inside prot streams 10 years
> ago... if now it is leaking into even worse places, well...

Here's the ktrace/kdump output on FreeBSD:

 45426 reconstruct CALL  access(0x80065d000,F_OK)
 45426 reconstruct NAMI  "/usr/local/lib/libsasl2.so.2"
 45426 reconstruct RET   access 0
 45426 reconstruct CALL  open(0x80065e000,O_RDONLY,<unused>0x763300)
 45426 reconstruct NAMI  "/usr/local/lib/libsasl2.so.2"
 45426 reconstruct RET   open 3
 45426 reconstruct CALL  fstat(0x3,0x7fffffffe350)
 45426 reconstruct STRU  struct stat {dev=87, ino=1084119, mode=-rwxr-xr-x , nlink=1, uid=0, gid=0, rdev=4338624, atime=1289519226, stime=1276299162, ctime=1289480449, birthtime=1276299162, size=114591, blksize=16384, blocks=224, flags=0x0 }
 45426 reconstruct RET   fstat 0
 45426 reconstruct CALL  pread(0x3,0x8007622e0,0x1000,0)
 45426 reconstruct GIO   fd 3 read 4096 bytes


What do you know fd 3.  It's almost certainly truss doing something
stupid.

We maybe be able to work around it in Cyrus - and that might actually be
worth it - but I don't think it's Cyrus' fault.

Bron.