emacs crash when open some newsgroups with gnus

emacs crash when open some newsgroups with gnus

[S.P.Tseng]

I subscribed the group "cn.bbs.comp.emacs" from "news.cn99.com". When I try to
open it from Group Buffer whit RET, and emacs crash.

Re: emacs crash when open some newsgroups with gnus

[S.P.Tseng]

S.P.Tseng <deftsp@gmail.com> writes:

> I subscribed the group "cn.bbs.comp.emacs" from "news.cn99.com". When I try to
> open it from Group Buffer whit RET, and emacs crash.
>
Sorry I forgot to give my emacs-version.

GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, X toolkit) of 2008-09-08.

Re: emacs crash when open some newsgroups with gnus

[S.P.Tseng]

S.P.Tseng <deftsp@gmail.com> writes:

> S.P.Tseng <deftsp@gmail.com> writes:
>
>> I subscribed the group "cn.bbs.comp.emacs" from "news.cn99.com". When I try to
>> open it from Group Buffer whit RET, and emacs crash.
>>
> Sorry I forgot to give my emacs-version.
>
> GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, X toolkit) of 2008-09-08.
>

More serious now. I open "gmane.emacs.devel" group from Group Buffer will cause
emacs crash too. 

Re: emacs crash when open some newsgroups with gnus

[S.P.Tseng]

S.P.Tseng <deftsp@gmail.com> writes:

> S.P.Tseng <deftsp@gmail.com> writes:
>
>> I subscribed the group "cn.bbs.comp.emacs" from "news.cn99.com". When I try to
>> open it from Group Buffer whit RET, and emacs crash.
>>
> Sorry I forgot to give my emacs-version.
>
> GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, X toolkit) of 2008-09-08.
>

"(define-coding-system-alias 'gbk 'gb2312)" for emacs22 tricked me.

Re: emacs crash when open some newsgroups with gnus

[Kenichi Handa]

In article <85wshcsa1y.fsf@modprobe.cn>, "S.P.Tseng" <deftsp@gmail.com> writes:

> S.P.Tseng <deftsp@gmail.com> writes:
> > S.P.Tseng <deftsp@gmail.com> writes:
> >
>>> I subscribed the group "cn.bbs.comp.emacs" from "news.cn99.com". When I try to
>>> open it from Group Buffer whit RET, and emacs crash.
>>> 
> > Sorry I forgot to give my emacs-version.
> >
> > GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, X toolkit) of 2008-09-08.
> >

> "(define-coding-system-alias 'gbk 'gb2312)" for emacs22 tricked me.

Do you mean that you had the above code in your .emacs, and
after deleting it, Emacs 23 doesn't crash anymore?

---
Kenichi Handa
handa@ni.aist.go.jp

Re: emacs crash when open some newsgroups with gnus

[S.P.Tseng]

Kenichi Handa <handa@m17n.org> writes:

> In article <85wshcsa1y.fsf@modprobe.cn>, "S.P.Tseng" <deftsp@gmail.com> writes:
>
>> S.P.Tseng <deftsp@gmail.com> writes:
>> > S.P.Tseng <deftsp@gmail.com> writes:
>> >
>>>> I subscribed the group "cn.bbs.comp.emacs" from "news.cn99.com". When I try to
>>>> open it from Group Buffer whit RET, and emacs crash.
>>>> 
>> > Sorry I forgot to give my emacs-version.
>> >
>> > GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, X toolkit) of 2008-09-08.
>> >
>
>> "(define-coding-system-alias 'gbk 'gb2312)" for emacs22 tricked me.
>
> Do you mean that you had the above code in your .emacs, and
> after deleting it, Emacs 23 doesn't crash anymore?
>

Yes.

> ---
> Kenichi Handa
> handa@ni.aist.go.jp

Re: emacs crash when open some newsgroups with gnus

[Kenichi Handa]

In article <853ak09tr5.fsf@modprobe.cn>, "S.P.Tseng" <deftsp@gmail.com> writes:

>>> "(define-coding-system-alias 'gbk 'gb2312)" for emacs22 tricked me.
> >
> > Do you mean that you had the above code in your .emacs, and
> > after deleting it, Emacs 23 doesn't crash anymore?
> >

> Yes.

I put that line in my .emacs, run Emacs 23, and visited
gmain.emacs.devel by Gnus, but couldn't reproduce the crash.

Please run Emacs under gdb and find at which point Emacs
crashes in your case.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: emacs crash when open some newsgroups with gnus

[S.P.Tseng]

Kenichi Handa <handa@m17n.org> writes:

> In article <853ak09tr5.fsf@modprobe.cn>, "S.P.Tseng" <deftsp@gmail.com> writes:
>
>>>> "(define-coding-system-alias 'gbk 'gb2312)" for emacs22 tricked me.
>> >
>> > Do you mean that you had the above code in your .emacs, and
>> > after deleting it, Emacs 23 doesn't crash anymore?
>> >
>
>> Yes.
>
> I put that line in my .emacs, run Emacs 23, and visited
> gmain.emacs.devel by Gnus, but couldn't reproduce the crash.
>
> Please run Emacs under gdb and find at which point Emacs
> crashes in your case.

I think I have found the reason.

After execute '(define-coding-system-alias 'gbk 'gb2312)', charset gbk will be
treated as charset gb2312. Emacs22 do not have the charset gbk, so that will be
fine. But Emacs23 support both. You know the charset gbk is bigger than gb2312,
when some char belong to charset gbk but be treated as gb2312 it will cause
overflow.

So, visited gmane.emacs.devel will or will not reproduce the crash.
But visited "cn.bbs.comp.emacs" from "new.cn99.com" can reproduce the crash.

How about when execute (define-coding-system-alias A B), if charset A is bigger than B,
give some warning or refuse?

Re: emacs crash when open some newsgroups with gnus

[Kenichi Handa]

In article <85ej3jm5uw.fsf@modprobe.cn>, "S.P.Tseng" <deftsp@gmail.com> writes:

> I think I have found the reason.

> After execute '(define-coding-system-alias 'gbk 'gb2312)', charset gbk will be
> treated as charset gb2312. Emacs22 do not have the charset gbk, so that will be
> fine. But Emacs23 support both. You know the charset gbk is bigger than gb2312,
> when some char belong to charset gbk but be treated as gb2312 it will cause
> overflow.

Coding system and charset are different concepts in Emacs,
and as far as I remember, I designed coding system in Emacs
23 not to crash even if one does (define-coding-system-alias
'gbk 'gb2312).  If it crashes in your case, there's a bug.
But, I can't reproduce the crash.  So, could you please find
where Emacs crashes, or show me an exact recipe to reproduce
the crash.

> How about when execute (define-coding-system-alias A B), if charset A is bigger than B,
> give some warning or refuse?

It may be a solution but at first I want to know which code
is wrong.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: emacs crash when open some newsgroups with gnus

[S.P.Tseng]

Kenichi Handa <handa@m17n.org> writes:

> So, could you please find where Emacs crashes, or show me an exact recipe to
> reproduce the crash.

Ok. I run emacs under gdb, eval '(define-coding-system-alias 'gbk 'gb2312)' and
visit "cn.bbs.comp.emacs" from "new.cn99.com" with gnus. 

This is the result.

,----
| (gdb) r emacs
| Starting program: /usr/local/bin/emacs emacs
| [Thread debugging using libthread_db enabled]
| [New Thread 0xb73b6720 (LWP 19823)]
| 
| Program received signal SIGSEGV, Segmentation fault.
| [Switching to Thread 0xb73b6720 (LWP 19823)]
| detect_coding_charset (coding=0xbfa2ca30, detect_info=0xbfa2cb20) at coding.c:5010
| 5010              dim = CHARSET_DIMENSION (charset);
`----


GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, X toolkit) of 2008-09-17 

Re: emacs crash when open some newsgroups with gnus

[Kenichi Handa]

In article <85od2lwy9h.fsf@modprobe.cn>, "S.P.Tseng" <deftsp@gmail.com> writes:

> This is the result.

> ,----
> | (gdb) r emacs
> | Starting program: /usr/local/bin/emacs emacs
> | [Thread debugging using libthread_db enabled]
> | [New Thread 0xb73b6720 (LWP 19823)]
> | 
> | Program received signal SIGSEGV, Segmentation fault.
> | [Switching to Thread 0xb73b6720 (LWP 19823)]
> | detect_coding_charset (coding=0xbfa2ca30, detect_info=0xbfa2cb20) at coding.c:5010
> | 5010              dim = CHARSET_DIMENSION (charset);
> `----

Thank you.  It seems that the variable charset gets invalid
here, but I still can't reproduce such a situation.

Please show me output of these commands:
(gdb) pp valids
(gdb) p/x c
(gdb) bt

And also send me the contents of the buffer Gnus was going
to decode at that time (as raw file; i.e. pre-decoded one).

---
Kenichi Handa
handa@ni.aist.go.jp

Re: emacs crash when open some newsgroups with gnus

[S.P.Tseng]

Kenichi Handa <handa@m17n.org> writes:

> In article <85od2lwy9h.fsf@modprobe.cn>, "S.P.Tseng" <deftsp@gmail.com> writes:
>
>> This is the result.
>
>> ,----
>> | (gdb) r emacs
>> | Starting program: /usr/local/bin/emacs emacs
>> | [Thread debugging using libthread_db enabled]
>> | [New Thread 0xb73b6720 (LWP 19823)]
>> | 
>> | Program received signal SIGSEGV, Segmentation fault.
>> | [Switching to Thread 0xb73b6720 (LWP 19823)]
>> | detect_coding_charset (coding=0xbfa2ca30, detect_info=0xbfa2cb20) at coding.c:5010
>> | 5010              dim = CHARSET_DIMENSION (charset);
>> `----
>
> Thank you.  It seems that the variable charset gets invalid
> here, but I still can't reproduce such a situation.
>
> Please show me output of these commands:
> (gdb) pp valids
> (gdb) p/x c
> (gdb) bt
>

pp is the command of gdb? or it's your alias. Anyway, i use p instead.

GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
(gdb) file emacs
Reading symbols from /usr/local/bin/emacs...done.
(gdb) run emacs
Starting program: /usr/local/bin/emacs emacs
[Thread debugging using libthread_db enabled]
[New Thread 0xb7389720 (LWP 29896)]

Program exited normally.
(gdb) run emacs
Starting program: /usr/local/bin/emacs emacs
[Thread debugging using libthread_db enabled]
[New Thread 0xb73fa720 (LWP 30720)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb73fa720 (LWP 30720)]
detect_coding_charset (coding=0xbfd6ed70, detect_info=0xbfd6ee60) at coding.c:5010
5010              dim = CHARSET_DIMENSION (charset);
(gdb) pp valids
Undefined command: "pp".  Try "help".
(gdb) p valids
$1 = 137919769
(gdb) p/x c
$2 = 0xfd
(gdb) bt
#0  detect_coding_charset (coding=0xbfd6ed70, detect_info=0xbfd6ee60) at coding.c:5010
#1  0x080b1a1c in detect_coding_system (src=0x993714c "realwhz@newsmth.net-SPAM.no (���\227�\223��)", src_chars=36, src_bytes=42, highest=1, multibytep=1, 
    coding_system=137919769) at coding.c:7757
#2  0x080b1d25 in Fdetect_coding_string (string=172056459, highest=137919817) at coding.c:7994
#3  0x08183347 in Ffuncall (nargs=3, args=0xbfd6ef30) at eval.c:3047
#4  0x081b7bf0 in Fbyte_code (bytestr=160319979, vector=142179020, maxdepth=<value optimized out>) at bytecode.c:678
#5  0x08185123 in funcall_lambda (fun=142179396, nargs=2, arg_vector=0xbfd6f074) at eval.c:3231
#6  0x0818304b in Ffuncall (nargs=3, args=0xbfd6f070) at eval.c:3101
#7  0x081b7bf0 in Fbyte_code (bytestr=160300363, vector=142179460, maxdepth=<value optimized out>) at bytecode.c:678
#8  0x08185123 in funcall_lambda (fun=142179580, nargs=1, arg_vector=0xbfd6f1a4) at eval.c:3231
#9  0x0818304b in Ffuncall (nargs=2, args=0xbfd6f1a0) at eval.c:3101
#10 0x081b7bf0 in Fbyte_code (bytestr=156728987, vector=141739692, maxdepth=<value optimized out>) at bytecode.c:678
#11 0x08184cc4 in Feval (form=161730133) at eval.c:2381
#12 0x08185851 in internal_lisp_condition_case (var=137919769, bodyform=161730133, handlers=161731245) at eval.c:1456
#13 0x081b8532 in Fbyte_code (bytestr=156108923, vector=163112044, maxdepth=<value optimized out>) at bytecode.c:868
#14 0x08184cc4 in Feval (form=161728125) at eval.c:2381
#15 0x08185851 in internal_lisp_condition_case (var=137919769, bodyform=161728125, handlers=161807285) at eval.c:1456
#16 0x081b8532 in Fbyte_code (bytestr=156109595, vector=170493924, maxdepth=<value optimized out>) at bytecode.c:868
#17 0x08185123 in funcall_lambda (fun=139383676, nargs=5, arg_vector=0xbfd6f724) at eval.c:3231
#18 0x0818304b in Ffuncall (nargs=6, args=0xbfd6f720) at eval.c:3101
#19 0x081b7bf0 in Fbyte_code (bytestr=158237403, vector=164451292, maxdepth=<value optimized out>) at bytecode.c:678
#20 0x08185123 in funcall_lambda (fun=138977268, nargs=1, arg_vector=0xbfd6f864) at eval.c:3231
#21 0x0818304b in Ffuncall (nargs=2, args=0xbfd6f860) at eval.c:3101
#22 0x081b7bf0 in Fbyte_code (bytestr=158236835, vector=166149828, maxdepth=<value optimized out>) at bytecode.c:678
#23 0x08185123 in funcall_lambda (fun=138101932, nargs=3, arg_vector=0xbfd6f9a4) at eval.c:3231
#24 0x0818304b in Ffuncall (nargs=4, args=0xbfd6f9a0) at eval.c:3101
#25 0x081b7bf0 in Fbyte_code (bytestr=158650707, vector=162085092, maxdepth=<value optimized out>) at bytecode.c:678
#26 0x08185123 in funcall_lambda (fun=170330580, nargs=6, arg_vector=0xbfd6fae4) at eval.c:3231
#27 0x0818304b in Ffuncall (nargs=7, args=0xbfd6fae0) at eval.c:3101
#28 0x081b7bf0 in Fbyte_code (bytestr=158651347, vector=164444252, maxdepth=<value optimized out>) at bytecode.c:678
#29 0x08185123 in funcall_lambda (fun=170327860, nargs=7, arg_vector=0xbfd6fc24) at eval.c:3231
#30 0x0818304b in Ffuncall (nargs=8, args=0xbfd6fc20) at eval.c:3101
#31 0x081b7bf0 in Fbyte_code (bytestr=170922563, vector=170923564, maxdepth=<value optimized out>) at bytecode.c:678
#32 0x08185123 in funcall_lambda (fun=170923780, nargs=2, arg_vector=0xbfd6fd64) at eval.c:3231
#33 0x0818304b in Ffuncall (nargs=3, args=0xbfd6fd60) at eval.c:3101
#34 0x081b7bf0 in Fbyte_code (bytestr=170922995, vector=170923852, maxdepth=<value optimized out>) at bytecode.c:678
#35 0x08185123 in funcall_lambda (fun=170923988, nargs=1, arg_vector=0xbfd6fe94) at eval.c:3231
#36 0x0818304b in Ffuncall (nargs=2, args=0xbfd6fe90) at eval.c:3101
#37 0x081b7bf0 in Fbyte_code (bytestr=171835843, vector=170469964, maxdepth=<value optimized out>) at bytecode.c:678
#38 0x08185123 in funcall_lambda (fun=169890644, nargs=1, arg_vector=0xbfd70014) at eval.c:3231
#39 0x0818304b in Ffuncall (nargs=2, args=0xbfd70010) at eval.c:3101
#40 0x08180f5c in Fcall_interactively (function=170811745, record_flag=137919769, keys=137958172) at callint.c:857
#41 0x0818332b in Ffuncall (nargs=4, args=0xbfd701d0) at eval.c:3050
#42 0x08183479 in call3 (fn=138083985, arg1=170811745, arg2=137919769, arg3=137919769) at eval.c:2874
#43 0x08127d6b in command_loop_1 () at keyboard.c:1880
#44 0x08182650 in internal_condition_case (bfun=0x81279d0 <command_loop_1>, handlers=137962977, hfun=0x81222b0 <cmd_error>) at eval.c:1511
#45 0x08121815 in command_loop_2 () at keyboard.c:1338
#46 0x0818272a in internal_catch (tag=137958953, func=0x81217f0 <command_loop_2>, arg=137919769) at eval.c:1247
#47 0x0812210f in command_loop () at keyboard.c:1317
#48 0x0812248b in recursive_edit_1 () at keyboard.c:942
#49 0x081225d4 in Frecursive_edit () at keyboard.c:1004
#50 0x08116ebb in main (argc=2, argv=0xbfd70894) at emacs.c:1693
(gdb) 


>
> And also send me the contents of the buffer Gnus was going
> to decode at that time (as raw file; i.e. pre-decoded one).

I just press RET from *Group* buffer of gnus. It only contain some group I
subscribe. And only do not alias gb2312 to gbk, gnus can open that group. You
can't reproduce such a situation, so you can get the contents of that buffer.

Re: emacs crash when open some newsgroups with gnus

[Kenichi Handa]

In article <85zlm5tyzn.fsf@modprobe.cn>, "S.P.Tseng" <deftsp@gmail.com> writes:

> pp is the command of gdb? or it's your alias. Anyway, i use p instead.

No.  It's defined in emacs/src/.gdbinit.  Excerpt from etc/DEBUG:

** When you debug Emacs with GDB, you should start it in the directory
where the executable was made.  That directory has a .gdbinit file
that defines various "user-defined" commands for debugging Emacs.
(These commands are described below under "Examining Lisp object
values" and "Debugging Emacs Redisplay problems".)

> > And also send me the contents of the buffer Gnus was going
> > to decode at that time (as raw file; i.e. pre-decoded one).

> I just press RET from *Group* buffer of gnus. It only contain some group I
> subscribe. And only do not alias gb2312 to gbk, gnus can open that group. You
> can't reproduce such a situation, so you can get the contents of that buffer.

Ummm.  You wrote:
> But visited "cn.bbs.comp.emacs" from "new.cn99.com" can reproduce the crash.

So, I did this (assuming that "from new.cn99.com" means
using news.cn99.com as the nntp server):

ESC : (define-coding-system-alias 'gbk 'gb2312)
ESC : (setq gnus-select-method '(nntp "news.cn99.com"))
M-x gnus RET

and visited "cn.bbs.comp.emacs".  But, my Emacs doesn't crash.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: emacs crash when open some newsgroups with gnus

[S.P.Tseng]

Kenichi Handa <handa@m17n.org> writes:

> In article <85zlm5tyzn.fsf@modprobe.cn>, "S.P.Tseng" <deftsp@gmail.com> writes:
>
>> pp is the command of gdb? or it's your alias. Anyway, i use p instead.
>
> No.  It's defined in emacs/src/.gdbinit.  Excerpt from etc/DEBUG:
>
> ** When you debug Emacs with GDB, you should start it in the directory
> where the executable was made.  That directory has a .gdbinit file
> that defines various "user-defined" commands for debugging Emacs.
> (These commands are described below under "Examining Lisp object
> values" and "Debugging Emacs Redisplay problems".)
>

I reproduce the crash again, follow what you said.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~---------------------------------------------------------
(git-master 10:55:%)$ gdb emacs
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
DISPLAY = :0.0
TERM = screen
Breakpoint 1 at 0x8116066: file emacs.c, line 417.
Breakpoint 2 at 0x81312d9: file sysdep.c, line 1135.
(gdb) r
Starting program: /home/tsp/src/emacs/src/emacs 
[Thread debugging using libthread_db enabled]
[New Thread 0xb747d720 (LWP 10913)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb747d720 (LWP 10913)]
detect_coding_charset (coding=0xbfbf38e0, detect_info=0xbfbf39d0) at coding.c:5010
5010              dim = CHARSET_DIMENSION (charset);
(gdb) pp valids
nil
(gdb) p/x c
$1 = 0xfd
(gdb) bt
#0  detect_coding_charset (coding=0xbfbf38e0, detect_info=0xbfbf39d0) at coding.c:5010
#1  0x080b1a1c in detect_coding_system (src=0xa2bf998 "realwhz@newsmth.net-SPAM.no (\300\276\301\275\301\227\301\223\300\275\300\243)", src_chars=36, src_bytes=42, 
    highest=1, multibytep=1, coding_system=137919769) at coding.c:7757
#2  0x080b1d25 in Fdetect_coding_string (string=172005003, highest=137919817) at coding.c:7994
#3  0x08183347 in Ffuncall (nargs=3, args=0xbfbf3aa0) at eval.c:3047
#4  0x081b7bf0 in Fbyte_code (bytestr=165698443, vector=165770884, maxdepth=<value optimized out>) at bytecode.c:678
#5  0x08185123 in funcall_lambda (fun=167478428, nargs=2, arg_vector=0xbfbf3be4) at eval.c:3231
#6  0x0818304b in Ffuncall (nargs=3, args=0xbfbf3be0) at eval.c:3101
#7  0x081b7bf0 in Fbyte_code (bytestr=165696947, vector=167511796, maxdepth=<value optimized out>) at bytecode.c:678
#8  0x08185123 in funcall_lambda (fun=167598548, nargs=1, arg_vector=0xbfbf3d14) at eval.c:3231
#9  0x0818304b in Ffuncall (nargs=2, args=0xbfbf3d10) at eval.c:3101
#10 0x081b7bf0 in Fbyte_code (bytestr=178322627, vector=178332604, maxdepth=<value optimized out>) at bytecode.c:678
#11 0x08184cc4 in Feval (form=178174197) at eval.c:2381
#12 0x08185851 in internal_lisp_condition_case (var=137919769, bodyform=178174197, handlers=178174013) at eval.c:1456
#13 0x081b8532 in Fbyte_code (bytestr=178322227, vector=178333812, maxdepth=<value optimized out>) at bytecode.c:868
#14 0x08184cc4 in Feval (form=178174357) at eval.c:2381
#15 0x08185851 in internal_lisp_condition_case (var=137919769, bodyform=178174357, handlers=178174885) at eval.c:1456
#16 0x081b8532 in Fbyte_code (bytestr=178321987, vector=178334252, maxdepth=<value optimized out>) at bytecode.c:868
#17 0x08185123 in funcall_lambda (fun=178334484, nargs=5, arg_vector=0xbfbf4294) at eval.c:3231
#18 0x0818304b in Ffuncall (nargs=6, args=0xbfbf4290) at eval.c:3101
#19 0x081b7bf0 in Fbyte_code (bytestr=178283659, vector=178284708, maxdepth=<value optimized out>) at bytecode.c:678
#20 0x08185123 in funcall_lambda (fun=178284892, nargs=1, arg_vector=0xbfbf43d4) at eval.c:3231
#21 0x0818304b in Ffuncall (nargs=2, args=0xbfbf43d0) at eval.c:3101
#22 0x081b7bf0 in Fbyte_code (bytestr=178284027, vector=178295428, maxdepth=<value optimized out>) at bytecode.c:678
#23 0x08185123 in funcall_lambda (fun=178295964, nargs=3, arg_vector=0xbfbf4514) at eval.c:3231
#24 0x0818304b in Ffuncall (nargs=4, args=0xbfbf4510) at eval.c:3101
#25 0x081b7bf0 in Fbyte_code (bytestr=178169571, vector=178188900, maxdepth=<value optimized out>) at bytecode.c:678
#26 0x08185123 in funcall_lambda (fun=178189404, nargs=6, arg_vector=0xbfbf4654) at eval.c:3231
#27 0x0818304b in Ffuncall (nargs=7, args=0xbfbf4650) at eval.c:3101
#28 0x081b7bf0 in Fbyte_code (bytestr=178169171, vector=178170140, maxdepth=<value optimized out>) at bytecode.c:678
#29 0x08185123 in funcall_lambda (fun=178170316, nargs=7, arg_vector=0xbfbf4794) at eval.c:3231
#30 0x0818304b in Ffuncall (nargs=8, args=0xbfbf4790) at eval.c:3101
#31 0x081b7bf0 in Fbyte_code (bytestr=176978643, vector=176980316, maxdepth=<value optimized out>) at bytecode.c:678
#32 0x08185123 in funcall_lambda (fun=176980532, nargs=2, arg_vector=0xbfbf48d4) at eval.c:3231
#33 0x0818304b in Ffuncall (nargs=3, args=0xbfbf48d0) at eval.c:3101
#34 0x081b7bf0 in Fbyte_code (bytestr=176979523, vector=176980604, maxdepth=<value optimized out>) at bytecode.c:678
#35 0x08185123 in funcall_lambda (fun=176980740, nargs=1, arg_vector=0xbfbf4a04) at eval.c:3231
#36 0x0818304b in Ffuncall (nargs=2, args=0xbfbf4a00) at eval.c:3101
#37 0x081b7bf0 in Fbyte_code (bytestr=178156219, vector=175472596, maxdepth=<value optimized out>) at bytecode.c:678
#38 0x08185123 in funcall_lambda (fun=176828972, nargs=1, arg_vector=0xbfbf4b84) at eval.c:3231
#39 0x0818304b in Ffuncall (nargs=2, args=0xbfbf4b80) at eval.c:3101
#40 0x08180f5c in Fcall_interactively (function=175633497, record_flag=137919769, keys=137958172) at callint.c:857
#41 0x0818332b in Ffuncall (nargs=4, args=0xbfbf4d40) at eval.c:3050
#42 0x08183479 in call3 (fn=138083985, arg1=175633497, arg2=137919769, arg3=137919769) at eval.c:2874
#43 0x08127d6b in command_loop_1 () at keyboard.c:1880
#44 0x08182650 in internal_condition_case (bfun=0x81279d0 <command_loop_1>, handlers=137962977, hfun=0x81222b0 <cmd_error>) at eval.c:1511
#45 0x08121815 in command_loop_2 () at keyboard.c:1338
#46 0x0818272a in internal_catch (tag=137958953, func=0x81217f0 <command_loop_2>, arg=137919769) at eval.c:1247
#47 0x0812210f in command_loop () at keyboard.c:1317
#48 0x0812248b in recursive_edit_1 () at keyboard.c:942
#49 0x081225d4 in Frecursive_edit () at keyboard.c:1004
#50 0x08116ebb in main (argc=1, argv=0xbfbf5404) at emacs.c:1693

Lisp Backtrace:
"detect-coding-string" (0xbfbf3aa4)
"rfc2047-decode-string" (0xbfbf3be4)
"mail-decode-encoded-address-string" (0xbfbf3d14)
---Type <return> to continue, or q <return> to quit--- 
"byte-code" (0xbfbf3dc0)
"byte-code" (0xbfbf3ff0)
"gnus-get-newsgroup-headers-xover" (0xbfbf4294)
"gnus-fetch-headers" (0xbfbf43d4)
"gnus-select-newsgroup" (0xbfbf4514)
"gnus-summary-read-group-1" (0xbfbf4654)
"gnus-summary-read-group" (0xbfbf4794)
"gnus-group-read-group" (0xbfbf48d4)
"gnus-group-select-group" (0xbfbf4a04)
"gnus-topic-select-group" (0xbfbf4b84)
"call-interactively" (0xbfbf4d44)
(gdb) 
~~~~~~~~~~-----------------------------------------------------------------------------------



> Ummm.  You wrote:
>> But visited "cn.bbs.comp.emacs" from "new.cn99.com" can reproduce the crash.
>
> So, I did this (assuming that "from new.cn99.com" means
> using news.cn99.com as the nntp server):
>
> ESC : (define-coding-system-alias 'gbk 'gb2312)
> ESC : (setq gnus-select-method '(nntp "news.cn99.com"))
> M-x gnus RET
>
> and visited "cn.bbs.comp.emacs".  But, my Emacs doesn't crash.

I do not know why. Perhaps some other code in my .gnus or .emacs have something
to with that matter. And I will give the debug information whatever you want.

>
> ---
> Kenichi Handa
> handa@ni.aist.go.jp

-- 
The opposite of love is not hate;
the opposite of love is solitude.

Re: emacs crash when open some newsgroups with gnus

[Kenichi Handa]

In article <85bpykj0c0.fsf@modprobe.cn>, "S.P.Tseng" <deftsp@gmail.com> writes:

> I reproduce the crash again, follow what you said.
[...]
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb747d720 (LWP 10913)]
> detect_coding_charset (coding=0xbfbf38e0, detect_info=0xbfbf39d0) at coding.c:5010
> 5010              dim = CHARSET_DIMENSION (charset);
> (gdb) pp valids
> nil

Ummm, this is strange.   I don't know why valids gets nil here.

> > and visited "cn.bbs.comp.emacs".  But, my Emacs doesn't crash.

> I do not know why. Perhaps some other code in my .gnus or .emacs have something
> to with that matter. And I will give the debug information whatever you want.

Then, please start Emacs with the arg -Q, eval
(define-coding-system-alias 'gbk 'gb2312), and check if it
still crashes.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: emacs crash when open some newsgroups with gnus

[S.P.Tseng]

Kenichi Handa <handa@m17n.org> writes:

> In article <85bpykj0c0.fsf@modprobe.cn>, "S.P.Tseng" <deftsp@gmail.com> writes:
>
>> I reproduce the crash again, follow what you said.
> [...]
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 0xb747d720 (LWP 10913)]
>> detect_coding_charset (coding=0xbfbf38e0, detect_info=0xbfbf39d0) at coding.c:5010
>> 5010              dim = CHARSET_DIMENSION (charset);
>> (gdb) pp valids
>> nil
>
> Ummm, this is strange.   I don't know why valids gets nil here.
>
>> > and visited "cn.bbs.comp.emacs".  But, my Emacs doesn't crash.
>
>> I do not know why. Perhaps some other code in my .gnus or .emacs have something
>> to with that matter. And I will give the debug information whatever you want.
>
> Then, please start Emacs with the arg -Q, eval
> (define-coding-system-alias 'gbk 'gb2312), and check if it
> still crashes.
>

Still crashes.

> ---
> Kenichi Handa
> handa@ni.aist.go.jp