<<< Date Index >>>     <<< Thread Index >>>

Re: mutt/2043: mutt invariably crashes when reading certain selected



The following reply was made to PR mutt/2043; it has been noted by GNATS.

From: Alain Bench <veronatif@xxxxxxx>
To: bug-any@xxxxxxxxxxxxx
Cc: Steven Schneider <steven_schneider@xxxxxxxxx>
Subject: Re: mutt/2043: mutt invariably crashes when reading certain selected
 e-mails
Date: Thu, 13 Oct 2005 16:52:51 +0200 (CEST)

 Hello Steven,
 
  On Sunday, October 9, 2005 at 11:47:39 -0600, Steven Schneider wrote=
 :
 
 > Oops, I'm sorry. I had thought I had sent this off some time ago.
 > Apparently it's been sitting in my account as a draft. :-)
 
     No problem, and thanks for the update: I feared you lost interest
 before giving us this last bit of info.
 
 
 > capital A tilde followed by the copyright sign in the xterm. From t=
 he
 > console it appears as a capital A followed by a small c.
 
     OK: The big A and small c are probably due to some form of
 approximate glyph mapping performed by the OpenBSD console driver, to
 workaround the VGA hardware default font (CP-437) not having uppercas=
 e A
 tilde nor copyright sign. The Linux console driver behaves similarly:
 Just it gives an *uppercase* C. If you copy/paste this A[cC] from
 console to xterm, it appears again as =C3=A9.
 
     Note I dislike such confusing display approximations, and load a
 full featured Latin-1 font to the VGA chargen at startup. Most Linux
 distributions do the same. "man setfont", console-tools, and so on.
 
 
 > I guess the environment setting didn't actually affect the output i=
 n
 > this case.
 
     Normal and expected: I was only surprised by your previous wordin=
 g.
 
 
 | set charset=3D"us-ascii//TRANSLIT"
 | charset-hook ^us-ascii$ cp1252
 > [viewing CP-1252 mislabelled US-Ascii] crashes when either of the
 > above lines. However, with both lines mutt doesn't crash.
 
     Very good, thank you: This validates at most possible that libico=
 nv
 1.9.2 and pl0 "signal 6, Aborted" crash is triggered by either invali=
 d
 (no 2nd line) or valid but unconvertable (no 1st line) character
 viewing.
 
     Such loosely related crashing scheme was encountred in the past,
 like the Glibc/UTF-8/regexec segfault. Mutt was found innocent, but
 where possible (overlong lines) implemented a workaround. Here I beli=
 eve
 we can't protect libiconv calls against invalid/unconvertable chars,
 because... Mutt finds what's inval/unconv by asking libiconv.
 
     Summary: OBSD libiconv 1.9.2pl1 solves the problem, and I believe=
  to
 be sufficiently sure nothing could be done in Mutt to prevent it, so =
 I
 close mutt/2043. Thank you again for the report and accurate infos: I=
 t
 had to be analysed thoroughly, in any case.
 
 
 > with the same version of libiconv compiled without patches on OpenB=
 SD
 > 3.8-beta, it didn't crash when reading those particular e-mails. Th=
 e
 > libiconv library that mutt crashes under was originally compiled un=
 der
 > OpenBSD 3.7-current.
 
     I don't know much about OpenBSD, and can't analyse this side of t=
 he
 problem. But perhaps some other /dev/mutt will have an explanation?
 
 
 Bye!=09Alain.
 --=20
 When you want to reply to a mailing list, please avoid doing so with
 Microsoft-Entourage/11. This lacks necessary references and breaks th=
 reads.