Re: index_format and <bar> vs <space>, segment fault
Hi, Alain,
I have read that bug report, although I do not understand it well.
It seems to be the same problem. Anyway, I will try my best to
give more details in this reply for your consideration. I do not
know whether it is useful for you, but I do hope mutt can be more
neat and perfect, although it is quite excellent now.
1. I must use gbk locale, because I need chinese language support,
and UTF-8 gives me a lot of trouble.
2. The segfault seems to be related closely to the gbk or gb2312 locale.
(2a): I use "mutt -nF /dev/null". The same segment fault is
reproduced. This operation eliminate the possibility of a wrong
muttrc file resulting in the segfault.
(2b): Keeping "LANG=zh_CN.GBK", using command "env
LANGUAGE=en_US mutt" result in the same segfault
(2c): Using "env LANG=en_US mutt", there is no segment fault.
As my understanding, this command set the LANG be en_US
temporarily. This time everything is fine(no segfault) although
the utf-8 code can not be displayed correct. It is amazing that
the chinese characters can also be displayed correctly in mutt
in this case. I know that if I set LANG=en_US in .xsession
directly and restart X, all the chinese characters can not be
displayed.
(2d): I also tested the gb2312 locale, it has the same segfault.
3. I encountered this segfault before, when I was searching a
pattern in the index, the error message is
"Compiling search pattern.....segment fault".
At that time, I thought it may due to some characters which can
not be treated by mutt, but I did not know what it is and where it
is. When I read Rado's message, I am sure that it is this utf-8
code message collapse my mutt when LANG=zh_CN.GBK. Maybe there are
still some other codeing leading to the same problem.
4. I am not familiar with gdb, and I do not know how to create a
coredump file. I use the following commands,
gdb mutt --> r --> bt
to produce the following messages in gdb, one is
segfault when reading Rado's utf-8 coded message:
#0 0xb7cb873f in memcpy () from /lib/tls/libc.so.6
#1 0xb7ce9996 in re_set_registers () from /lib/tls/libc.so.6
#2 0xb7ce9c55 in re_set_registers () from /lib/tls/libc.so.6
#3 0xb7cfe110 in re_compile_pattern () from /lib/tls/libc.so.6
#4 0xb7cfe9b9 in regexec () from /lib/tls/libc.so.6
#5 0x0808e80d in ?? ()
#6 0x0814ac80 in ?? ()
#7 0xbfa99e40 in ?? ()
#8 0x00000001 in ?? ()
#9 0xbfa9a658 in ?? ()
#10 0x00000000 in ?? ()
the other is segfault when searching a pattern:
Program received signal SIGSEGV, Segmentation fault.
0xb7ce873f in memcpy () from /lib/tls/libc.so.6
(gdb) bt
#0 0xb7ce873f in memcpy () from /lib/tls/libc.so.6
#1 0xb7d19996 in re_set_registers () from /lib/tls/libc.so.6
#2 0xb7d19c55 in re_set_registers () from /lib/tls/libc.so.6
#3 0xb7d2e110 in re_compile_pattern () from /lib/tls/libc.so.6
#4 0xb7d2e9b9 in regexec () from /lib/tls/libc.so.6
#5 0x080962f1 in ?? ()
#6 0x081b62f8 in ?? ()
#7 0x081a09e8 in ?? ()
#8 0x00000000 in ?? ()
they seem to be the same.
Ye Fei
On 2006-06-15, Alain Bench (veronatif@xxxxxxx) wrote:
> Hello,
>
> On Monday, June 12, 2006 at 9:02:21 +0200, Ye Fei wrote:
>
> > When reading Rado's message, my Mutt (Mutt 1.5.11+cvs20060403) stops
> > working. It quits with a segment fault.
>
> Take a look at the yet unsolved Debian Bug#339555 "Segmentation
> fault when displaying a iso8859-1 mail header" to study if that's the
> same thing. Especially check first the gdb backtrace.
>
>
> > some "characters" which can not be treated correctly by mutt in the
> > zh_CN.GBK locale.
>
> Only a small minority of the Latin-1 chars of Rado's table are
> displayable in a GBK locale. Mutt is able to display them, and masks
> other ones with a question mark. That's the best you can have, unless
> you change to a better terminal and locale, or use //TRANSLITerations.
>
>
> > The original message by Rado is attached below.
>
> How did you manage to quote it without segfault: <list-reply>
> directly from index?
>
>
> >| LANGUAGE=en_CN:en_US:en_GB:en:zh_CN
>
> BTW: Unset it (unless you have a good reason).
>
>
> >| set charset="gbk"
>
> Drop it.
>
>
> >| charset-hook ^gb2312$ gbk
>
> Are you sure this really makes sense?
>
>
> >| charset-hook ^iso-8859-1$ gbk
> >| charset-hook !utf-8 gbk
>
> Whatever intent you had, this looks to me like self-foot-shooting,
> twice ;-). All incoming mails (outside of UTF-8 ones) are treated as if
> they contained GBK. Which would be fine, if all mails really contained
> GBK. But when mails contain whatever else, this gives you garbage.
> Better drop both lines, and review original intent searching another
> solution with fewer drawbacks.
>
>
> Bye! Alain.
> --
> When you want to reply to a mailing list, please avoid doing so with
> Lotus Notes 5. This lacks necessary references and breaks threads.