Segfault when opening forwarded multipart email (as attachment) before sending about neomutt HOT 5 OPEN

I started looking into this. Here's a backtrace:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x70)
  * frame #0: 0x00000001000b0834 neomutt`mutt_attach_display_loop(sub=0x0000000140707c40, menu=0x00000001418062c0, op=31, e=0x0000000122a04d70, actx=0x00000001418c42e0, recv=false) at recvattach.c:981:23
    frame #1: 0x00000001000a0eb4 neomutt`op_display_headers(shared=0x000000014183e9b0, op=31) at functions.c:2023:5
    frame #2: 0x000000010009d7c0 neomutt`compose_function_dispatcher(win=0x0000000141893240, op=31) at functions.c:2156:12
    frame #3: 0x000000010009d108 neomutt`dlg_compose(e=0x0000000122a04d70, fcc=0x000000016fdfbbb8, flags='\0', sub=0x0000000140707c40) at dlg_compose.c:356:10
    frame #4: 0x000000010008d3c4 neomutt`mutt_send_message(flags=0, e_templ=0x0000000122a04d70, tempfile="/var/folders/6p/pdh_lfv143sc6nhsg0q54f6w0000gn/T/neomutt-dennis-schoen-501-35723-15226520958842890192", m=0x0000000000000000, ea=0x000000016fdfbc80, sub=0x0000000140707c40) at send.c:2713:9
    frame #5: 0x000000010003ea1c neomutt`attach_forward_bodies(fp=0x00000001dbe2e4e0, e=0x00000001223a6950, actx=0x0000000122a04ae0, b=0x00000001223a6f10, nattach=0) at recvcmd.c:627:3
    frame #6: 0x000000010003db04 neomutt`mutt_attach_forward(fp=0x00000001dbe2e4e0, e=0x00000001223a6950, actx=0x0000000122a04ae0, b=0x00000001223a6f10, flags=0) at recvcmd.c:799:5
    frame #7: 0x00000001000a90f8 neomutt`op_forward_message(priv=0x0000000122a04ca0, op=107) at functions.c:569:3
    frame #8: 0x00000001000a7fe4 neomutt`attach_function_dispatcher(win=0x0000000122a046d0, op=107) at functions.c:732:12
    frame #9: 0x00000001000a79a4 neomutt`dlg_attachment(sub=0x0000000140707c40, mv=0x00000001406cb990, e=0x00000001223a6950, fp=0x00000001dbe2e4e0, attach_msg=false) at dlg_attach.c:532:10
    frame #10: 0x0000000100050f94 neomutt`op_view_attachments(shared=0x0000000141826820, priv=0x0000000141826970, op=233) at functions.c:2496:5
    frame #11: 0x0000000100049ea8 neomutt`index_function_dispatcher(win=0x00000001418269a0, op=233) at functions.c:3285:12
    frame #12: 0x000000010004986c neomutt`dlg_index(dlg=0x0000000141826760, m_init=0x000000014060ab80) at dlg_index.c:1336:10
    frame #13: 0x0000000100027590 neomutt`main(argc=1, argv=0x000000016fdfd750, envp=0x000000016fdfd760) at main.c:1387:11
    frame #14: 0x00000001851d10e0 dyld`start + 2360

from neomutt.

@roccoblues , the code I wrote to handle recalling postponed and resending messages is in 9350145

from neomutt.

I can reproduce this.

I suspect this use case was probably missed in the multipart code I originally worked on to fix up.

I notice that the attachment tree is wrongly displayed which further suggests that it was never implemented or tested and certainly indicates that the attachment structure is broken leading to an inevitable segfault.

In theory it's probably not too hard to fix, but I haven't looked at the code for a long time.

David

from neomutt.

The fix probably needs to happen in attach_forward_bodies (or somewhere in recvcmd.c).

Previously multipart mime types where just treated as a back box, so this probably worked. (Although there were a lot of bugs, so often things just worked by luck.) But now the compose code expects them to be attached as a tree structure.

The code probably more or less exists because the send from a postponed message code is capable of creating the attachment tree from a multipart attachment. But there are more cases that potentially need to be handled here. You can forward anything, but only create multipart/alternative, multipart/multilingual and multipart/related. So there are possibly unwise assumptions about what kinds of multipart attachments will appear while composing. The postpone code strips multipart/mixed and crypt multiparts.

It's conceivable you might want to forward a multipart/mixed attachment I guess (not sure?). Forwarding an encrypted attachment seems somewhat pointless, but maybe there is a use case. I can see how you might want to forward a signed attachment. Although the receiver would need to find some custom way of verifying the signature.

All this is to say that it's not quite as simple to fix as I hoped. Some design and behaviour decisions need to be made. @roccoblues if you want to do it you are welcome :). I can tinker, but no timeline promises.

from neomutt.

@dcpurton Thanks for the info. I have the bad feeling this might be a bit over my head but I'll at least try to understand the problem.

Previously multipart mime types where just treated as a back box, so this probably worked.

I stepped through the code and mutt_body_copy is used to copy the body. It seems like this is doing what you describe above - black box copy. So we have to update or replace that with a version that actually copies the tree structure (loop through b->next)?

The code probably more or less exists because the send from a postponed message code is capable of creating the attachment tree from a multipart attachment

Can you point me to that code? Thanks!

from neomutt.