On 2021-11-18 09:59:15, Antoine Beaupré wrote:
> 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...
I'm a little hesitant in sharing more of my ignorance because it's kind
of embarrassing, but here's more data from the core file.
(gdb) p vars.data
$2 = {
data = 0x559f9c642e00 "X-TUID: GovLn9FNVKrB\n[placeholder] \n It is
anticipated that there will eventually come a time where the\n third party
ecosystem surrounding Python 3 is sufficiently mature\n for this
recommendation t"..., len = 1388, date = 0, flags = 0 '\000'}
Interestingly, it is *definitely* a corrupt message in the mailspool. It
seems to have been truncated somehow:
```
anarcat@marcos:~/Maildir$ cat .notmuch/cur/1536068601.M123540P18521Q127.curie:2,
It is anticipated that there will eventually come a time where the
third party ecosystem surrounding Python 3 is sufficiently mature
for this recommendation to be updated to suggest that the python
symlink refer to python3 rather than python2.
And from right up at the beginning [2]:
however, end users should be aware that python refers to python3 on
at least Arch Linux (that change is what prompted the creation of
this PEP), so python should be used in the shebang line only for
scripts that are source compatible with both Python 2 and 3.
On my Gentoo system, I've also selected Python 3 to back ‘python’. So
I think your solution should be “add a /usr/bin/python symlink to your
python3”, not “claim that nmbug is only compatible with Python 3”.
Cheers,
Trevor
[1]:
https://www.python.org/dev/peps/pep-0394/#future-changes-to-this-recommendation
[2]: https://www.python.org/dev/peps/pep-0394/#abstract
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20180209/00270767/attachment.sig>
```
i frankly don't have a clear idea of what that thing is. It seems it's a
mail that was extracted from a mailman mbox file, which is possible: i
have at some point imported the notmuch archives in my
mailspool. Something terrible seems to have happened to that
message. Here is the original:
https://nmbug.notmuchmail.org/nmweb/show/20180209204624.GL30368%40valgrind.us
Anyways, long story short, I think I found the culprit and, in theory, a
way to reproduce. Drop the above bytes in a file in
`Maildir/.notmuch/cur/`, serve the folder over Dovecot, connect to it
with mbsync, and the crash should happen.
Obviously, there's corruption on the mail spool, but less obviously, I
don't think mbsync should crash on it either way.
I still can't quite figure out a fix for the crash, but I'm confident
enough it doesn't have confidential information that i'll forward the
core file in private.
--
On ne peut s'empêcher de vieillir, mais on peut s'empêcher de devenir
vieux.
- Henri Matisse
_______________________________________________
isync-devel mailing list
isync-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/isync-devel
