Conversation

Jarkko Sakkinen

Edited 3 months ago
(gdb) print boxes
$1 = {0x5555556c4540, <optimized out>}

I noticed this so I tried:

diff --git a/src/main_sync.c b/src/main_sync.c
index 226e324..afb23ca 100644
--- a/src/main_sync.c
+++ b/src/main_sync.c
@@ -623,6 +623,7 @@ sync_opened( main_vars_t *mvars, int t )
if (!mvars->chanptr->boxlist && mvars->chan->patterns) {
mvars->chanptr->boxlist = 2;
char **boxes[2];
+ __asm__ __volatile__("" :: "m" (boxes));
boxes[F] = filter_boxes( mvars->boxes[F], mvars->chan->boxes[F], mvars->chan->patterns );
boxes[N] = filter_boxes( mvars->boxes[N], mvars->chan->boxes[N], mvars->chan->patterns );
box_ent_t **mboxapp = &mvars->chanptr->boxes;

That literally fixed the bug! I.e. could this be a #GCC bug?

RT @gromit, @adamw

#mbsync #gcc #fedora #bug #isync
1
0
0
@adamw @gromit It totally works now. Creative workarounds...
1
0
0
@adamw @gromit I compiled mbsync from upstream without my workaround using clang, and that version works also without glitches, so I'm pretty sure that this might be an actual GCC 14 bug..
1
0
0

@jarkko @adamw with this type of weird failure, did you try to disable LTO?

1
0
1
@gromit @adamw

Sorry I was too busy having a weekend but here's a screen cast that proves that -fno-lto addresses the issue :-)

I definitely going to check also later on https://gitlab.archlinux.org/archlinux/packaging/packages/isync/-/issues/1 but at sight I don't really believe this is the same issue, it fails elsewhere. Obviously this can be considered most as guess because I don't know how the internals of mbsync interact with each other.
1
0
0
@gromit @adamw [it hurts my head that the project is called "isync" the artifact is called "mbsync"]
0
0
0