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: Fri, 19 Aug 2005 16:11:23 +0200 (CEST)
On Thursday, August 18, 2005 at 7:00:18 PM -0600, Steven Schneider wrote:
> I'm not exactly sure whom to send this too, so I hope it's alright if
> I send it to you. If not, just point me in the right direction and
> I'll make sure to send it that way. :-)
Normally, the better is to send to our brand new BTS's address
bug-any@xxxxxxxxxxxxx, while preserving the "mutt/2043:" tag in subject.
Everybody should be able to see the data, the web and mutt-dev. There is
an exception for sensitive privacy or security data that should not be
public, of course.
But for now we still have an annoying problem with BTS to mutt-dev
forwarding when the sender is not subscribed to the mailing list. So
copy me additionally, please. If you $honor_followup_to, it should be
automagic on [g] <group-reply>.
For the audit trail record, I bounced your message to BTS and
uploaded the crashing mail example.
> The only relevant mailcap entry I can think of is
>| text/html; lynx -dump -force_html %s; nametemplate=%s.html; copiousoutput
> Though I have
>| alternative_order text/plain text/enriched text/html
> in my muttrc.
OK: So lynx is not involved, only the plain alternative is displayed
by Mutt alone.
> In between the time I send off the report and when I received your
> e-mail I have recompiled my libiconv library from libiconv-1.9.2p0 to
> libiconv-1.9.2p1. I don't know if this changes the results of the
> backtrace, but the core is from when I was running mutt compiled with
> libiconv-1.9.2p0.
Thanks for the precision. Upgrade should not have changed backtrace
of the original core. Problem is more that I could not infer anything
usefull, perhaps someone else will have a clue?
> Now I have to attempt to attach or insert one of the offending
> e-mails.
Thanks, well received. Doesn't crash here: Both plain or HTML
alternatives display OK. But this gave me a clue:
>| Content-Type: text/plain; charset="us-ascii"
>| Content-Transfer-Encoding: 7bit
Ascii/7bits label. A lie. Content was really CP-1252 8 bits. While
your own mail where you inserted this crashing example was:
> Content-Type: text/plain; charset=iso-8859-1; format=flowed
> Content-Transfer-Encoding: 8bit
Latin-1/8bits. A lie also. This means you have something broken in
iconv, locale, or charset settings. Could this have lead to the crash?
Hum... Perhaps. Let's explore this. Could you please give us output of:
| $ mutt -v
| $ printenv | egrep "^(LANG|LC_)" | sort
| $ egrep "charset|iconv" ~/.mutt/muttrc # and all sourced files
And in Mutt itself (that's $charset variable &reset then ?show):
| :set &charset ?charset
Also temporarily add the following 2 lines to muttrc, and check if
the same mail still crashes:
| set charset="us-ascii//TRANSLIT"
| charset-hook ^us-ascii$ cp1252
> I don't know if any of this helps, especially considering that I'm
> using a different libconv library. Still, I hope it proves to be
> useful.
I don't know: Never seen such crash, and have no experience about
OpenBSD locales. Hoping also. At least libiconv 1.9.2 is a solid thing.
Bye! Alain.
--
Mutt muttrc tip for mailing lists: set followup_to=yes and declare the list as
- subscribe ^list@ddress$ if you are subscribed and don't want courtesy copy.
- lists ^list@ddress$ if you are not subscribed or want a courtesy copy.