#81 Segmentation fault from referencing NULL srec->msg

[Paul Walker]

Hi

I'm getting a periodic segmentation fault while running mbsync. For context - there is mbsync process running every 5 minutes using mu4e, and one running from crontab which syncs the large Gmail mailboxes.

I don't know if it will make any difference but this is running under FreeBSD 14.1. I'm building from the git repo on commit:

* 3c4b5f1 - (HEAD -> master, origin/master, origin/HEAD) remove stray closing brace from man page (6 weeks ago) <Ludovico Gerardi>

Unfortunately I don't think I can just send you the core file - it's got email details in it - but I'm happy to get debug info for you.

~/built/bin/mbsync --version
isync 1.5.0-7-g3c4b5f1

Core was generated by `/home/pw921828/built/bin/mbsync -q gmail-boxes'.
Program terminated with signal SIGSEGV, Segmentation fault.
Address not mapped to object.
#0  box_loaded (sts=0, msgs=0x24122055fc80, total_msgs=122103, recent_msgs=0, aux=0x24121ff90d00) at sync.c:1233
1233                                            nflags = srec->msg[xt^1]->flags;
(gdb) bt
#0  box_loaded (sts=0, msgs=0x24122055fc80, total_msgs=122103, recent_msgs=0, aux=0x24121ff90d00) at sync.c:1233
#1  0x0000000000415c7a in imap_submit_load_p3 (ctx=0x24121fe46980, sts=0x24121ffb21a0) at drv_imap.c:3173
#2  0x0000000000415bea in imap_submit_load_p2 (ctx=0x24121fe46980, cmd=0x24121ff6bbd0, response=0) at drv_imap.c:3167
#3  0x000000000040f100 in done_imap_cmd (ctx=0x24121fe46980, cmd=0x24121ff6bbd0, response=0) at drv_imap.c:359
#4  0x000000000041307b in imap_socket_read (aux=0x24121fe46980) at drv_imap.c:1928
#5  0x000000000040ac83 in socket_filled (conn=0x24121fe46b20, len=14) at socket.c:848
#6  0x000000000040ad8f in socket_fill_z (sock=0x24121fe46b20) at socket.c:878
#7  0x000000000040ae35 in socket_fill (sock=0x24121fe46b20) at socket.c:894
#8  0x000000000040bbda in socket_fd_cb (events=1, aux=0x24121fe46b20) at socket.c:1251
#9  0x00000000004067e4 in event_wait () at util.c:1124
#10 0x0000000000406820 in main_loop () at util.c:1198
#11 0x000000000042b2b1 in sync_chans (cvars=0x82129c2e0, argv=0x82129c3c0) at main_sync.c:392
#12 0x000000000042a1f9 in main (argc=3, argv=0x82129c3a8) at main.c:582
(gdb) print *srec
$2 = {next = 0x241220493ac0, uid = {163385, 0}, msg = {0x0, 0x0}, status = 16, flags = 0 '\000', pflags = 0 '\000', aflags = "\000", dflags = "\000", tuid = '\000' <repeats 11 times>}

I have also seen an assertion failure come up once or twice; I'll post details on that next time it recurs.

[Oswald Buddenhagen]

oh, wow, somebody is apparently actually using MaxMessages. :-o

the crash is obviously due to srec->msg[xt^1] being null, but i don't know why that is the case. please add -D to the command line and attach the log (or mail it to me privately).

[Paul Walker]

"Oswald Buddenhagen" ossi@users.sourceforge.net writes:

oh, wow, somebody is apparently actually using MaxMessages. :-o

Not commonly used? Maybe I should turn it off (after we've found
the cause of this crash!).

the crash is obviously due to srec->msg[xt^1] being null, but i
don't know why that is the case. please add -D to the
command line and attach the log (or mail it to me privately).

Will do; I haven't actually seen it since I reported the issue
(always the way), but I'll keep looking out for it.

[Oswald Buddenhagen]

i'm aware of one other person using it, in a way it really was not intended.
but the code is actually rather heavily auto-tested, so nothing to worry about per se. in fact, if you managed to add a failing case to run-tests.pl, that would be ideal, though this is obviously a somewhat tall order.

[Oswald Buddenhagen]

it looks like the problem is triggered by a server-side message having disappeared after a transaction to propagate it was started and then interrupted.
copying the null check from line 1214 is presumably an adequate fix, but i still need to consider the bigger picture, e.g. if pulling it ahead would be appropriate. and come up with an autotest.

[Paul Walker]

As a data point, copying the null check does fix the crash. That said, it's a bit hard to follow what the code's doing, but it doesn't feel like a good fix.

[Oswald Buddenhagen]

it looks a bit hacky at first sight, but the pointers being null is actually legit.
will commit as-is.

[Paul Walker]

Great - thanks for fixing it. :)