Hi,
I was using 1.4.4 from the Fedora repos. This occurs when I use the repo
version, and when compiled with -O2 (default) in commit
e70c300f7446ba6ec1259f459a0f0e1d2d592ed9.
My uname -a is:
Linux runxiyu-fedora 6.8.9-405.asahi.fc40.aarch64+16k #1 SMP PREEMPT_DYNAMIC
Wed May 22 12:33:25 UTC 2024 aarch64 GNU/Linux
Compiling with -Og -g seems to cause it to run successfully.
The configuration is pretty standard:
IMAPAccount runxiyu
Host mail.runxiyu.org
User m...@runxiyu.org
PassCmd "pass show runxiyu.org/me"
SSLType IMAPS
#TLSType IMAPS
#CertificateFile /etc/ssl/certs/ca-certificates.crt
IMAPStore runxiyu-remote
Account runxiyu
MaildirStore runxiyu-local
SubFolders Verbatim
Path ~/.local/share/mail/runxiyu/
Inbox ~/.local/share/mail/runxiyu/Inbox
Channel runxiyu
Far :runxiyu-remote:
Near :runxiyu-local:
Patterns *
Create Both
Expunge Both
SyncState *
Note that I only experience this error when ~/.local/share/mail/runxiyu is
empty. If I have a successful previous run, subsequent syncs work.
Running it causes a segfault.
$ gdb -args /usr/bin/mbsync -c ~/.config/mbsync/config --verbose runxiyu
...
(gdb) run
Starting program: /usr/bin/mbsync -c /home/runxiyu/.config/mbsync/config
--verbose runxiyu
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Reading configuration file /home/runxiyu/.config/mbsync/config
C: 0/1 B: 0/0 F: +0/0 *0/0 #0/0 N: +0/0 *0/0 #0/0
Channel runxiyu
Opening far side store runxiyu-remote...
ok
Connecting to mail.runxiyu.org (155.138.132.239:993)...
Opening near side store runxiyu-local...
Connection is now encrypted
Logging in...
Authenticating with SASL mechanism PLAIN...
[Detaching after vfork from child process 138602]
Program received signal SIGSEGV, Segmentation fault.
0x0000aaaaaaabba34 in sync_chans (mvars=0xffffffffe090, ent=<optimized out>) at
/usr/src/debug/isync-1.4.4-8.fc40.aarch64/src/main.c:906
906 char *sname = boxes[N] ? boxes[N][sb] :
NULL;
Backtrace:
#0 0x0000aaaaaaabba34 in sync_chans (mvars=0xffffffffe090, ent=<optimized
out>) at /usr/src/debug/isync-1.4.4-8.fc40.aarch64/src/main.c:906
#1 0x0000aaaaaaabe9d0 [PAC] in imap_list_store_p3 (sts=0xaaaaaac55b40,
ctx=<optimized out>) at
/usr/src/debug/isync-1.4.4-8.fc40.aarch64/src/drv_imap.c:3408
#2 imap_list_store_p3 (sts=0xaaaaaac55b40, ctx=<optimized out>) at
/usr/src/debug/isync-1.4.4-8.fc40.aarch64/src/drv_imap.c:3406
#3 imap_list_store_p2 (ctx=<optimized out>, cmd=<optimized out>,
response=<optimized out>) at /usr/src/debug/isync-1.4.4-8.fc40.aarch64/src/drv_imap.c:3402
#4 0x0000aaaaaaabe67c [PAC] in done_imap_cmd (ctx=ctx@entry=0xaaaaaaaf55f0,
cmd=cmd@entry=0xaaaaaac5b8d0, response=<optimized out>)
at /usr/src/debug/isync-1.4.4-8.fc40.aarch64/src/drv_imap.c:326
#5 0x0000aaaaaaac814c [PAC] in imap_socket_read (aux=0xaaaaaaaf55f0) at
/usr/src/debug/isync-1.4.4-8.fc40.aarch64/src/drv_imap.c:1750
#6 0x0000aaaaaaab1b80 [PAC] in event_wait () at
/usr/src/debug/isync-1.4.4-8.fc40.aarch64/src/util.c:831
#7 main_loop () at /usr/src/debug/isync-1.4.4-8.fc40.aarch64/src/util.c:903
#8 main (argc=<optimized out>, argv=<optimized out>) at
/usr/src/debug/isync-1.4.4-8.fc40.aarch64/src/main.c:797
Valgrind says it's an "invalid read of size 8".
I tried compiling after
CFLAGS="-Og -g" ./configure --with-zlib
but then the problem just goes away. "-O1" also doesn't crash.
But compiling with "-O2" crashes. "-g" doesn't affect things so I kept it
enabled to make my life easier.
0x000000000042f014 in sync_opened (mvars=0xffffffffe500, t=<optimized out>) at
main_sync.c:631
631 char *nname = boxes[N] ? boxes[N][sb] : NULL;
(gdb) backtrace
#0 0x000000000042f014 in sync_opened (mvars=0xffffffffe500, t=<optimized out>)
at main_sync.c:631
#1 0x000000000041e174 in imap_list_store_p3 (ctx=<optimized out>,
sts=0x5c1eb0) at drv_imap.c:3664
#2 imap_list_store_p3 (ctx=<optimized out>, sts=0x5c1eb0) at drv_imap.c:3662
#3 imap_list_store_p2 (ctx=<optimized out>, cmd=<optimized out>,
response=<optimized out>) at drv_imap.c:3658
#4 0x000000000041b3ec in done_imap_cmd (ctx=ctx@entry=0x4655f0,
cmd=cmd@entry=0x5a96c0, response=0) at drv_imap.c:363
#5 0x0000000000420ad8 in imap_socket_read (aux=0x4655f0) at drv_imap.c:1951
#6 0x0000000000413fa8 in event_wait () at util.c:1124
#7 main_loop () at util.c:1198
#8 0x000000000042f8e8 in sync_chans (cvars=cvars@entry=0xffffffffe610,
argv=<optimized out>) at main_sync.c:391
#9 0x0000000000411510 in main (argc=<optimized out>, argv=0xffffffffe838) at
main.c:582
Invalid read of size 8
at 0x42F014: sync_opened.part.0 (main_sync.c:631)
by 0x41E173: imap_list_store_p3 (drv_imap.c:3664)
by 0x41E173: imap_list_store_p3 (drv_imap.c:3662)
by 0x41E173: imap_list_store_p2 (drv_imap.c:3658)
by 0x41B3EB: done_imap_cmd (drv_imap.c:363)
by 0x420AD7: imap_socket_read (drv_imap.c:1951)
by 0x413FA7: event_wait (util.c:1124)
by 0x413FA7: main_loop (util.c:1198)
by 0x42F8E7: sync_chans (main_sync.c:391)
by 0x41150F: main (main.c:582)
Address 0x0 is not stack'd, malloc'd or (recently) free'd
Process terminating with default action of signal 11 (SIGSEGV)
Access not within mapped region at address 0x0
at 0x42F014: sync_opened.part.0 (main_sync.c:631)
by 0x41E173: imap_list_store_p3 (drv_imap.c:3664)
by 0x41E173: imap_list_store_p3 (drv_imap.c:3662)
by 0x41E173: imap_list_store_p2 (drv_imap.c:3658)
by 0x41B3EB: done_imap_cmd (drv_imap.c:363)
by 0x420AD7: imap_socket_read (drv_imap.c:1951)
by 0x413FA7: event_wait (util.c:1124)
by 0x413FA7: main_loop (util.c:1198)
by 0x42F8E7: sync_chans (main_sync.c:391)
by 0x41150F: main (main.c:582)
If you believe this happened as a result of a stack
overflow in your program's main thread (unlikely but
possible), you can try to increase the size of the
main thread stack using the --main-stacksize= flag.
The main thread stack size used in this run was 8388608.
"N" seems to be 1, and "sb" seems to be 0, before the segfaulty line. I'm
personally unfamiliar with gdb and related tools, the above numbers came
from printf.
I have no idea how the code structure of mbsync works, and the meaning of
variables aren't very obvious to me. I'll leave it here, please have a look.
Thanks!
--
Regards,
Runxi Yu (they/them)
https://runxiyu.org/
_______________________________________________
isync-devel mailing list
isync-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/isync-devel
