Re: Mutt crashing on exit or replying (sometimes)
On Fri, Mar 06, 2009 at 03:44:45PM -0600, Kyle Wheeler wrote:
> On Friday, March 6 at 02:15 PM, quoth Joshua Tinnin:
> >> This may have nothing to do with your problem, but: setting the
> >> $charset variable manually is ALMOST NEVER a good idea! I've only
> >> ever seen *one* situation where it's even *useful*.
> >
> > I typically need more than just 7-bit text, however.
>
> So do I! But that means you have to establish an 8-bit environment,
> not just force your programs to spit out 8-bit characters and hope
> that everything makes good guesses about what's going on.
>
> > I'm really not sure how to get it to use unicode without my
> > specifying it. Is there something I'm missing? I wish the
> > documentation had warned me.
>
> The *correct* way of informing programs like mutt (so that all of the
> system libraries they rely on behave properly) is to use environment
> variables, specifically LANG (and, if you need them, the LC_*
> variables as well).
>
> Step 1 of establishing a UTF-8 environment is getting a terminal
> program that supports it. Most of them do these days, but you need to
> run them with the right flags. For example, xterm supports UTF-8, but
> requires a bunch of flags to enable it, so they usually provide the
> `uxterm` script in order to launch xterm in UTF-8 mode. The rxvt
> terminal has a similar script (I think it's `urxvt`).
Yeah, although the same issues are present whether I use Eterm, urxvt or
just a console, though screen and ssh, or on its own. FreeBSD's console
doesn't support UTF, however, but xterm does.
I should reiterate: this only happens through one of my mutt rc files. I
use two others which have no issues, but I can't see any differences
between them which might cause this. I'm wondering if it has something
to do with the mailbox files themselves, although changing folders in
another mutt with a different rc file to the folders in question will
not reproduce the problem.
> Step 2 is making sure you have UTF-8 fonts. This all depends on your
> OS, and I don't know the specifics of doing it with FreeBSD (with
> luck, you already have them).
>
> Step 3 is exporting the right environment variables - you can read the
> `locale` man page for details. Personally, I set LANG to be
> en_US.UTF-8, but you have to use `locale -a` (or something similar) to
> find out what encodings are available on your machine. (en means
> "english", US means "american", and UTF-8 means the character set) For
> example, on my OSX box...
>
> $ locale -a | grep en_US
> en_US
> en_US.ISO8859-1
> en_US.ISO8859-15
> en_US.US-ASCII
> en_US.UTF-8
>
> Often times, the uxterm/urxvt terminal scripts will set up your
> environment variables correctly for you, so you don't have to muck
> with them. However, many terminals do NOT set these things up for you
> (e.g. I don't believe gnome-terminal does, and I *know* Apple Terminal
> doesn't either). Chances are you want to add some logic to your
> ~/.bashrc (or equivalent for your shell) to set the LANG environment
> variable correctly for your machine.
>
> (There are lots of tricks to detecting the correct locale setting for
> your terminal, depending on the environment. For example, in an X11
> environment, as long as you have a $WINDOWID environment variable, you
> can use the xprop program to find out what locale that window is
> using.)
>
> The tricky part of this is that in many cases the wrong settings can
> produce acceptable results *most* of the time.
>
> It IS, however, important to use environment variables. For example,
> mutt may use system library calls like "isalpha()", which base their
> answers on what locale they think they're in. Usually, they default to
> US-ASCII, and since that's the basis for most character sets, it
> usually produces acceptable results. But when someone sends you a
> message that uses a character that isn't in US-ASCII, those functions
> can get it wrong UNLESS they and mutt are both aware of the right
> character set.
OK, I've already previously set the locale in my zshrc:
export LANG=en_US.UTF-8
Also, here's what my zsh environment returns:
% locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=
> >> It'd probably be more helpful if you ran mutt inside a debugger and
> >> gave us a backtrace.
> >
> > How do you do that? Again, I'm not a programmer. I'm running it compiled
> > with debug flags and with the debug level set at 5.
>
> Usually, just load up mutt with the following command:
>
> gdb /usr/local/bin/mutt
>
> And then at the prompt, type "run". When mutt crashes, it will return
> you to the prompt, at which point you can type "backtrace". (To get
> out of it, type "quit".)
OK, this is what I get:
Program received signal SIGSEGV, Segmentation fault.
0x080b2746 in ?? ()
(gdb) backtrace
#0 0x080b2746 in ?? ()
#1 0x00000000 in ?? ()
#2 0x28626000 in ?? ()
#3 0x00000080 in ?? ()
#4 0x28863f20 in ?? ()
#5 0x28716c20 in ?? ()
#6 0x28716ac0 in ?? ()
#7 0xbfbfae98 in ?? ()
#8 0x0809e4af in ?? ()
#9 0x00000300 in ?? ()
#10 0x00000014 in ?? ()
#11 0x00000074 in ?? ()
#12 0x28860a00 in ?? ()
#13 0x28873fb0 in ?? ()
#14 0x28873f10 in ?? ()
#15 0xbfbfaec8 in ?? ()
#16 0x080a41ce in ?? ()
#17 0x28716c20 in ?? ()
#18 0x00000000 in ?? ()
#19 0xbfbfc47c in ?? ()
#20 0x080b2778 in ?? ()
#21 0x28861160 in ?? ()
#22 0xbfbfc47c in ?? ()
#23 0x00000025 in ?? ()
#24 0x28873fb0 in ?? ()
#25 0x28873f10 in ?? ()
#26 0x00000001 in ?? ()
#27 0xbfbfc888 in ?? ()
#28 0x080a5102 in ?? ()
#29 0x28860a00 in ?? ()
#30 0x080e7b19 in ?? ()
#31 0x0000049f in ?? ()
#32 0x00000000 in ?? ()
#33 0x00000000 in ?? ()
#34 0x00000000 in ?? ()
#35 0x00000000 in ?? ()
#36 0x285e9918 in ?? () from /lib/libc.so.7
#37 0x00000400 in ?? ()
#38 0xbfbfb16c in ?? ()
#39 0xbfbfb008 in ?? ()
#40 0x00000000 in ?? ()
#41 0xbfbfafa4 in ?? ()
#42 0x080e0dc4 in ?? ()
#43 0xbfbfb024 in ?? ()
#44 0x285c61e1 in snprintf () from /lib/libc.so.7
Previous frame inner to this frame (corrupt stack?)
I'm not sure what to make of this, honestly ... This is the new library
for FreeBSD 7, but not sure how to read that error.
- jt
> >> What version of libiconv do you use? There's some buggy ones out
> >> there (esp. on FreeBSD) that are known to cause crashes. You may
> >> just need to update your iconv library.
> >
> > Well, right now it's libiconv-1.11_1. I'll run an update and see if a
> > newer version is available.
>
> Hmmm. 1.11 should be good.
>
> See about that backtrace; that'll give a much better idea of what's
> going on and where it's crashing.
>
> ~Kyle
> --
> Science is what we can tell a computer. Art is everything else.
> -- Knuth