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.