[Dovecot] Assertion Failure in mbox-sync.c
Timo Sirainen
tss at iki.fi
Tue May 24 00:59:45 EEST 2005
On 18.5.2005, at 03:00, Todd Burroughs wrote:
>> sync_ctx->input is different than sync_ctx->file_input, where the
>> statbuf was taken from (took a while to notice this :). Could you do
>> the
>> same for it?
>
> There's an odd value in here...
> I checked and the values look correct, other than st_size.
That's a gdb bug (or gcc debug information writer bug or something).
64bit numbers seem to be quite often broken with gdb. Usually they can
be fixed by just discarding the highest 32 bits, but with struct stat
the whole st_size seems to points to wrong location.
> I don't think that NFS would return an older value, as there is one
> system
> wide cache per machine. It is possible to turn caching off, so I could
> test this. My understanding is that the client will cache attributes
> for
> some period of time, 3 to 60 seconds are the default min/max for Linux.
> I don't know how it determines how long it actually caches them for.
Right, I thought about this too after sending the mail. The caching
problem could happen only if another computer modified the file, so the
test program couldn't really trigger it.
But included a patch to Dovecot, it should give some more information
now instead of just crashing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dovecot-mbox-size-check.diff
Type: application/octet-stream
Size: 1169 bytes
Desc: not available
URL: <http://dovecot.org/pipermail/dovecot/attachments/20050524/8ac8e500/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://dovecot.org/pipermail/dovecot/attachments/20050524/8ac8e500/attachment-0001.bin>
More information about the dovecot
mailing list