Hello,
On Sat, 02 May 2026 at 01:02:10 +0200, Piotr Masłowski via isync-devel wrote:
> Hello list,
>
> I am another person who has encountered this bug. I also have some new
> findings. E.g. that this assertion can be hit even on v1.5.0!
I can also replicate the assertion triggering on a fresh build of mbsync
v1.5.1 with an analogous config file. So it's definitely a bug in
upstream.
FWIW, I spent a bit stepping through execution with GDB and it seems the
problem may be that proxy_create_box() is never being called. Which
causes the following chain:
(1) The proxy store state (proxy_store_t) member 'is_fake' is seemingly
supposed to be set to 1 in proxy_do_create_box() when dry-running.
But since proxy_create_box() is not called, the value of 'is_fake'
remains 0. From proxy_do_create_box():
if (DFlags & DRYRUN) {
ctx->is_fake = 1;
proxy_create_box_cb( DRV_OK, cmd );
} else {
ctx->real_driver->create_box( ... );
}
(2) When proxy_do_open_box() is called, another member 'fake_nextuid'
should be set to 1 if 'is_fake' is nonzero. But since 'is_fake' is
0, 'fake_nextuid' also remains 0. From proxy_do_open_box():
if (ctx->is_fake) {
ctx->fake_nextuid = 1;
proxy_open_box_cb( DRV_OK, 1, cmd );
} else {
ctx->real_driver->open_box( ... );
}
(3) When proxy_do_store_msg() is called for the first time (on the
Maildir side), proxy_store_msg_cb() is called with sts=DRV_OK and
uid=ctx->fake_nextuid++, so sts=DRV_OK and uid=0. Then
proxy_store_msg_cb() calls cmd->callback(), which is msg_copied() on
the Maildir side, with the same sts and uid values.
Now sts, reinterpreted as COPY_OK, causes the sync state for the
near side to have the ST_FIND_NEW bit added to it. From
msg_copied():
switch (sts) {
case COPY_OK:
if (!uid) // Stored to a non-UIDPLUS mailbox
svars->state[t] |= ST_FIND_NEW;
else
ASSIGN_UID( ... );
(4) When msgs_copied() is called after all messages have been "copied",
the find_new_msgs() Maildir callback is called, due to the addition
of ST_FIND_NEW. From msg_copied():
if (svars->state[t] & ST_FIND_NEW) {
debug( ... );
svars->drv[t]->find_new_msgs( ... );
} else {
msgs_new_done( svars, t );
}
This calls (after some proxy redirection) maildir_find_new_msgs(),
where the assertion is triggered, presumably because we should never
have ended up here.
I can't yet say what the fix may be, but perhaps this info may
nonetheless be useful.
Take care,
Seth McDonald.
--
E9D1 26A5 F0D4 9DF7 792B C2E2 B4BF 4530 D39B 2D51
_______________________________________________
isync-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/isync-devel
