GNU bug report logs - #36431
Crash in marker.c:337

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Werner LEMBERG <wl <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 36431 <at> debbugs.gnu.org
Subject: bug#36431: Crash in marker.c:337
Date: Sun, 30 Jun 2019 17:52:13 +0300

> Date: Sun, 30 Jun 2019 09:26:26 +0200 (CEST)
> Cc: eliz <at> gnu.org, 36431 <at> debbugs.gnu.org
> From: Werner LEMBERG <wl <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.