bug#36431: Crash in marker.c:337

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 30 Jun 2019 09:26:26 +0200 (CEST)
> Cc: eliz@gnu.org, 36431@debbugs.gnu.org
> From: Werner LEMBERG <wl@gnu.org>
> 
> My problem is that I have no idea how to reproduce the problem without
> mew.  What approach do you suggest?

From the backtrace, I see that the chain of calls is this:

  "insert-file-contents" (0xffff8ff8)
  "apply" (0xffff8ff0)
  "mew-insert-file-contents2" (0xffff95e8)
  "apply" (0xffff95e0)
  "mew-insert-file-contents" (0xffff9a40)
  "mew-encode-mime-body" (0xffffa250)
  "mew-encode-singlepart" (0xffffa830)
  "mew-encode-multipart" (0xffffadb0)
  "mew-encode-make-multi" (0xffffb2f0)
  "mew-smtp-encode-message" (0xffffb870)
  "mew-smtp-encode" (0xffffbd40)
  "mew-draft-smtp-process-message" (0xffffc2a0)
  "mew-draft-process-message" (0xffffc790)
  "mew-draft-send-message" (0xffffce80)

So my suggestion would be to try to find out what should be the buffer
contents before the call to insert-file-contents, and what should be
in the file being inserted, to reproduce the problem, and then post
the data needed for the reproduction.

If you cannot figure this out on the level of insert-file-contents,
try going up the call stack, and find the lowest level where you can
figure out the arguments and their values, including the contents of
any files needed for the reproduction.  Then show the results, and we
will try to use the relevant mew code to fill in the blanks.

One caveat: your mew customizations might be part of the puzzle, so be
sure to spell them out.

Thanks.