On 2021-11-18 10:22:31, Oswald Buddenhagen wrote:
> On Wed, Nov 17, 2021 at 07:57:59PM -0500, Antoine Beaupré wrote:
>>totally frustrating, on the one hand. on the other hand: yay bug
>>solved?
>>:p
>>
> :'-D
>
>>maybe the gdb backtrace could be of use?
>>
> depends on how local the problem is. if it's near the crash site,
> careful code review might reveal it. if it's not ...
>
>> i might still have the core file around if you need to inspect
>>some state...
>
> that might be definitely useful, as i might find the triggering input
> that way. note that it will contain the plain text of some messages (the
> current one in full, and the remainder(s) of the biggest one(s), but
> what exactly would be possible to reconstruct depends on the allocator's
> behavior).
is there a way I could inspect those structures myself to just do a
quick check of what i'd be leaking?
i looked a bit at the backtrace again and it seems the crash happens on
line 534 in sync.c, which is:
(gdb)
#5 0x0000559f9b9b01a7 in copy_msg_convert (vars=0x559f9c6445a0,
out_cr=<optimized out>, in_cr=<optimized out>) at ./src/sync.c:534
534 free( in_buf );
(gdb) l
529 copy_msg_bytes( &out_buf, in_buf, &idx, in_len, in_cr, out_cr );
530
531 if (vars->minimal)
532 memcpy( out_buf, dummy_msg_buf, dummy_msg_len );
533
534 free( in_buf );
535 return 1;
536 }
537
538 static void
in_buf is a char* pointer to vars->data.data, with vars being passed as
an argument to the function. it seems odd that this buffer gets freed
there in the first place... but I don't know enough about the
architecture of that code to tell. it certainly looks a bit messy, if I
may... ;) Now I understand why you want valgrind to figure out where
this is coming from, it's kind of a needle in a haystack to track the
origin of in_buf in there...
Maybe someone more familiar with that piece of the code could figure it
out better than me, that said...
> oh, and your config file might be useful, just in case this is triggered
> by a less tested feature.
i somehow managed to recreate the crash by clearing my local store and
redoing a full sync, which is interesting in and on itself.
here is my config:
SyncState *
Sync New ReNew Flags
# IMAP side, AKA "Far" AKA "Master" in pre 1.4
IMAPAccount anarcat
Host imap.anarc.at
User anarcat
PassCmd "pass imap.anarc.at"
SSLType IMAPS
CertificateFile /etc/ssl/certs/ca-certificates.crt
IMAPStore anarcat-remote
Account anarcat
# Maildir side, AKA "Near"
MaildirStore anarcat-local
# Maildir/top/sub/sub
#SubFolders Verbatim
# Maildir/.top.sub.sub
SubFolders Maildir++
# Maildir/top/.sub/.sub
# SubFolders legacy
# The trailing "/" is important
#Path ~/Maildir-mbsync/
Inbox ~/Maildir-mbsync/
# what binds Maildir and IMAP
Channel anarcat
# AKA Far, convert when all clients are 1.4+
Master :anarcat-remote:
# AKA Near
Slave :anarcat-local:
# Exclude everything under the internal [Gmail] folder, except the interesting
folders
#Patterns * ![Gmail]* "[Gmail]/Sent Mail" "[Gmail]/Starred" "[Gmail]/All Mail"
# Or include everything
#Patterns *
Patterns * !register !.register
# Automatically create missing mailboxes, both locally and on the server
#Create Both
Create slave
# Sync the movement of messages between folders and deletions, add after making
sure the sync works
#Expunge Both
IMAPAccount anarcat-register
Host imap.anarc.at
User register
PassCmd "pass imap.anarc.at-register"
SSLType IMAPS
CertificateFile /etc/ssl/certs/ca-certificates.crt
IMAPStore anarcat-register-remote
Account anarcat-register
MaildirStore anarcat-register-local
SubFolders Maildir++
Inbox ~/Maildir-mbsync/.register/
Channel anarcat-register
Master :anarcat-register-remote:
Slave :anarcat-register-local:
Create slave
i'm trying to run things under valdgrind and -D now, to pinpoint which
message is causing the crash. i did a first run and it seemed to hang on
the network, then either valgrind restarted mbsync (!?) or it restarted
itself and i lost the backlog. I didn't have debugging symbols installed
anyways, so the valgrind info wasn't exactly useful.
I'll report back later with the valgrind report.
a.
--
Code is law.
- Lawrence Lessig
_______________________________________________
isync-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/isync-devel
