Gnus crash

Gnus crash

[Eduardo Muñoz]

In GNU Emacs 21.2.1 (i386-msvc-nt5.0.2195)
 of 2002-09-27 on EMF
configured using `configure --with-msvc (12.00) --cflags /Ox'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ESN
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t


A korean spam message manged to crash Emacs while 
using Gnus. I can reproduce the crash with only two 
files, a bare bones .gnus and an one-message mbox.
I included both files at the en of the post.
The home dir to reproduce the crash looks like this:

Home/
    .gnus
    Mail/
        Inbox

Steps to reproduce the crash
start emacs
M-x gnus
No server defined (or somesuch) (Continue? y or n) y RET
G m RET Inbox RET nnfolder RET
;; Now you can see the Inbox group
RET ;; enter the group and voilá Emacs crashes

Emacs Abort Dialog
Select Abor/Retry/Ignore 

-> Retry 

Exception 0x80000003 at address 0x88f9f9df

The key is in `gnus-summary-line-format´ "%-70,70s".
The crash will happen when the summary line is wider 
than the emacs frame AND the subject has korean 
characters.


-------.gnus----------
(setq gnus-select-method '(nnfolder "Inbox"))
(setq gnus-summary-line-format
      "%U%R%z%I%(%[%4L: %-20,20n%]%) %-70,70s\n")
-------.gnus----------

-------Inbox----------
>From kcs4718@dreamwiz.com  Sat Jan 11 22:44:51 2003
Received: from dreamwiz.com ([218.54.77.211])
	by mx.jet.es (8.11.6/8.11.6) with SMTP id h0BDime26818
	for <emf@jet.es>; Sat, 11 Jan 2003 14:44:49 +0100 (MET)
X-Gnus-Mail-Source: 
Message-Id: <200301111344.h0BDime26818@mx.jet.es>
X-Envelope-To: <emf@jet.es>
Reply-To: kcs4718@dreamwiz.com
From: ¹Ì·¡ <kcs4718@dreamwiz.com>
To: <emf@jet.es>
Subject: (±¤°í)¼ö¼ö·á¾ø´Â ´ëÃâ ¾ÈÀüÇØ¿ä
Sender: ¹Ì·¡ <kcs4718@dreamwiz.com>
Mime-Version: 1.0
Content-Type: text/html; charset="ks_c_5601-1987"
Date: Sat, 11 Jan 2003 22:44:51 +0900
X-UIDL: @_4"!,%6"!R~O!!7/m"!
Lines: 134
Xref: EMF Inbox:731
X-Gnus-Article-Number: 731   Sat Jan 11 15:47:47 2003

<Content cut>
-------Inbox----------

HTH


-- 

Eduardo Muñoz

Re: Gnus crash

[ShengHuo ZHU]

"Eduardo Muñoz" <emufer@terra.es> writes:

[...]

> A korean spam message manged to crash Emacs while 
> using Gnus. I can reproduce the crash with only two 
> files, a bare bones .gnus and an one-message mbox.
> I included both files at the en of the post.
> The home dir to reproduce the crash looks like this:
>
> Home/
>     .gnus
>     Mail/
>         Inbox
>
> Steps to reproduce the crash
> start emacs
> M-x gnus
> No server defined (or somesuch) (Continue? y or n) y RET
> G m RET Inbox RET nnfolder RET
> ;; Now you can see the Inbox group
> RET ;; enter the group and voilá Emacs crashes
>
> Emacs Abort Dialog
> Select Abor/Retry/Ignore 
>
> -> Retry 
>
> Exception 0x80000003 at address 0x88f9f9df
>
> The key is in `gnus-summary-line-format´ "%-70,70s".
> The crash will happen when the summary line is wider 
> than the emacs frame AND the subject has korean 
> characters.
>
>
> -------.gnus----------
> (setq gnus-select-method '(nnfolder "Inbox"))
> (setq gnus-summary-line-format
>       "%U%R%z%I%(%[%4L: %-20,20n%]%) %-70,70s\n")
> -------.gnus----------

I can not reproduce the bug in my GNU/Linux box. Probably it is
related to displaying Korean fonts in MS Windows.  Could you somehow
post a backtrace of the exception?

ShengHuo

Re: Gnus crash

[Eduardo Muñoz]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:
> I can not reproduce the bug in my GNU/Linux box. Probably it is
> related to displaying Korean fonts in MS Windows.  Could you somehow
> post a backtrace of the exception?

This is what MSVC++ debugger tells me.
I don't know if it will be helpfull.

------ Call Stack --------------
> NTDLL! 77f9f9df()
  EMACS! 0109ec8b()
  EMACS! 0109ebf0()
  EMACS! 0109d037()
  EMACS! 0109ec7d()
  EMACS! 0109f5ed()
  EMACS! 0109ad0d()
  EMACS! 0109fa6c()
  EMACS! 0109f6c4()
  EMACS! 0109ad0d()
  EMACS! 0109fa6c()
  EMACS! 0109f6c4()
  EMACS! 0109ad0d()
  EMACS! 0109fa6c()
  EMACS! 0109f6c4()
  EMACS! 0109ad0d()
  EMACS! 0109fa6c()
  EMACS! 0109f6c4()
  EMACS! 0109ad0d()
  EMACS! 0109fa6c()
  EMACS! 0109f6c4()
  EMACS! 0109ad0d()
  EMACS! 0109fa6c()
  EMACS! 0109f6c4()
  EMACS! 0109a59d()
  EMACS! 01015636()
  EMACS! 0100def2()
  EMACS! 0109ddff()
  EMACS! 0100d39b()
  EMACS! 0100d33c()
  EMACS! 010e0b73()
  KERNEL32! 77e87903()

------ Registers ---------------
  EAX = 00000000 EBX = 0082F5AE ECX = 0082FFB0 EDX = 0218007A ESI = 0FFFFFFF EDI = 0165796F
  EIP = 77F9F9DF ESP = 0082F54C EBP = 0082F5F8 EFL = 00000246
  MM0 = 00D500D400D300D2 MM1 = 00DD00DC00DB00DA MM2 = 00C500C400C300C2 MM3 = 00CD00CC00CB00CA MM4 = FF00000000000000
  MM5 = 0000000000000000 MM6 = F7A55E4000000000 MM7 = 0000000000000000
  XMM0 = 00190018001700160015001400130012 XMM1 = 00210020001F001E001D001C001B001A XMM2 = 00290028002700260025002400230022
  XMM3 = 00310030002F002E002D002C002B002A XMM4 = 00390038003700360035003400330032 XMM5 = 00410040003F003E003D003C003B003A
  XMM6 = 00490048004700460045004400430042 XMM7 = 00510050004F004E004D004C004B004A
  CS = 001B DS = 0023 ES = 0023 SS = 0023 FS = 0038 GS = 0000 OV=0 UP=0 EI=1 PL=0 ZR=1 AC=0 PE=1 CY=0
  XMM00 = +1.74490E-039 XMM01 = +1.92857E-039 XMM02 = +2.11225E-039 XMM03 = +2.29592E-039
  XMM10 = +2.47959E-039 XMM11 = +2.66327E-039 XMM12 = +2.84694E-039 XMM13 = +3.03062E-039
  XMM20 = +3.21429E-039 XMM21 = +3.39796E-039 XMM22 = +3.58164E-039 XMM23 = +3.76531E-039
  XMM30 = +3.94899E-039 XMM31 = +4.13266E-039 XMM32 = +4.31633E-039 XMM33 = +4.50001E-039
  XMM40 = +4.68368E-039 XMM41 = +4.86735E-039 XMM42 = +5.05103E-039 XMM43 = +5.23470E-039
  XMM50 = +5.41838E-039 XMM51 = +5.60205E-039 XMM52 = +5.78572E-039 XMM53 = +5.96940E-039
  XMM60 = +6.15307E-039 XMM61 = +6.33674E-039 XMM62 = +6.52042E-039 XMM63 = +6.70409E-039
  XMM70 = +6.88777E-039 XMM71 = +7.07144E-039 XMM72 = +7.25511E-039 XMM73 = +7.43879E-039 MXCSR = 00001F80
  ST0 = +0.00000000000000000e+0000 ST1 = +0.00000000000000000e+0000 ST2 = +0.00000000000000000e+0000
  ST3 = +0.00000000000000000e+0000 ST4 = +2.55000000000000000e+0002 ST5 = +0.00000000000000000e+0000
  ST6 = +2.07740496000000000e+0009 ST7 = +0.00000000000000000e+0000
  CTRL = 027F STAT = 0120 TAGS = FFFF EIP = 0100AD68
  CS = 001B DS = 0023 EDO = 0082F504


------ Disassembly -------------
  [...]
  77F9F9CD   cmp         dword ptr [ebp-24h],0
  77F9F9D1   je          77F9F9DB
  77F9F9D3   push        dword ptr [ebp-24h]
  77F9F9D6   call        77F8F9D1
  77F9F9DB   ret
  77F9F9DC   ret         4
> 77F9F9DF   int         3
  77F9F9E0   ret
  77F9F9E1   int         3
  77F9F9E2   ret
  77F9F9E3   mov         eax,dword ptr [esp+4]
  77F9F9E7   int         3
  77F9F9E8   ret         4
  77F9F9EB   mov         eax,dword ptr [ebp-14h]
  77F9F9EE   mov         eax,dword ptr [eax]
  77F9F9F0   mov         eax,dword ptr [eax]
  77F9F9F2   mov         dword ptr [ebp-280h],eax
  77F9F9F8   push        1
  77F9F9FA   pop         eax
  77F9F9FB   ret
  77F9F9FC   mov         esp,dword ptr [ebp-18h]
  77F9F9FF   mov         esi,dword ptr [ebp-280h]
  77F9FA05   or          dword ptr [ebp-4],0FFFFFFFFh
  77F9FA09   xor         ebx,ebx
  77F9FA0B   jmp         77F98213
  77F9FA10   mov         eax,fs:[00000018]
  77F9FA16   mov         byte ptr [eax+0F74h],bl
  77F9FA1C   mov         eax,esi
  77F9FA1E   jmp         77F98277
  77F9FA23   mov         eax,200h
  77F9FA28   mov         byte ptr [ebp-19h],0Ah
  77F9FA2C   jmp         77F9822A
  77F9FA31   mov         dword ptr [ebp-27Ch],40010006h
  77F9FA3B   mov         dword ptr [ebp-274h],ebx
  77F9FA41   mov         dword ptr [ebp-26Ch],2
  77F9FA4B   mov         dword ptr [ebp-278h],ebx
  77F9FA51   movzx       eax,word ptr [ebp-228h]
  77F9FA58   inc         eax
  77F9FA59   mov         dword ptr [ebp-268h],eax
  77F9FA5F   mov         eax,dword ptr [ebp-224h]
  77F9FA65   mov         dword ptr [ebp-264h],eax
  77F9FA6B   lea         eax,[ebp-27Ch]
  77F9FA71   push        eax
  77F9FA72   call        77FB0360
  77F9FA77   mov         eax,fs:[00000018]
  77F9FA7D   mov         byte ptr [eax+0F74h],bl
  77F9FA83   xor         eax,eax
  77F9FA85   jmp         77F98277
  77F9FA8A   push        1
  77F9FA8C   call        77F9F9E3
  77F9FA91   xor         ecx,ecx
  77F9FA93   jmp         77F98269
  77F9FA98   push        ebp
  77F9FA99   mov         ebp,esp
  77F9FA9B   sub         esp,258h
  77F9FAA1   lea         eax,[ebp+0Ch]
  77F9FAA4   push        eax
  77F9FAA5   lea         eax,[ebp-258h]
  77F9FAAB   push        dword ptr [ebp+8]
  [...]


-- 

Eduardo Muñoz

Re: Gnus crash

[Kenichi Handa]

In article <usmvzsjbm.fsf@terra.es>, "Eduardo =?iso-8859-1?q?Mu=F1oz?=" <emufer@terra.es> writes:
> A korean spam message manged to crash Emacs while 
> using Gnus. I can reproduce the crash with only two 
> files, a bare bones .gnus and an one-message mbox.
> I included both files at the en of the post.
> The home dir to reproduce the crash looks like this:

> Home/
>     .gnus
>     Mail/
>         Inbox

> Steps to reproduce the crash
> start emacs
> M-x gnus
> No server defined (or somesuch) (Continue? y or n) y RET
> G m RET Inbox RET nnfolder RET
> ;; Now you can see the Inbox group
> RET ;; enter the group and voilá Emacs crashes

> Emacs Abort Dialog
> Select Abor/Retry/Ignore 

> ->  Retry 

> Exception 0x80000003 at address 0x88f9f9df

> The key is in `gnus-summary-line-format´ "%-70,70s".
> The crash will happen when the summary line is wider 
> than the emacs frame AND the subject has korean 
> characters.

Thank you for the report.  This bug was already fixed in the
CVS HEAD by the attached patch.  Eduardo, could you please
try the attached patch?

---
Ken'ichi HANDA
handa@m17n.org

2002-01-02  Richard M. Stallman  <rms@gnu.org>
[...]
	* editfns.c (Fformat): Update thissize from field_width
	based on the actual width, in the string case.

Index: editfns.c
===================================================================
RCS file: /cvs/emacs/src/editfns.c,v
retrieving revision 1.324
retrieving revision 1.325
diff -u -c -r1.324 -r1.325
cvs server: conflicting specifications of output style
*** editfns.c	18 Dec 2001 02:15:53 -0000	1.324
--- editfns.c	2 Jan 2002 19:56:50 -0000	1.325
***************
*** 3217,3222 ****
--- 3217,3223 ----
      if (*format++ == '%')
        {
  	int thissize = 0;
+ 	int actual_width = 0;
  	unsigned char *this_format_start = format - 1;
  	int field_width, precision;
  
***************
*** 3297,3302 ****
--- 3298,3304 ----
  	    if (*format != 's' && *format != 'S')
  	      error ("Format specifier doesn't match argument type");
  	    thissize = CONVERTED_BYTE_SIZE (multibyte, args[n]);
+ 	    actual_width = lisp_string_width (args[n], -1, NULL, NULL);
  	  }
  	/* Would get MPV otherwise, since Lisp_Int's `point' to low memory.  */
  	else if (INTEGERP (args[n]) && *format != 's')
***************
*** 3350,3356 ****
  	    goto string;
  	  }
  
! 	thissize = max (field_width, thissize);
  	total += thissize + 4;
        }
  
--- 3352,3358 ----
  	    goto string;
  	  }
  
! 	thissize += max (0, field_width - actual_width);
  	total += thissize + 4;
        }
  

Re: Gnus crash

[Kenichi Handa]

In article <usmvzsjbm.fsf@terra.es>, "Eduardo =?iso-8859-1?q?Mu=F1oz?=" <emufer@terra.es> writes:
> A korean spam message manged to crash Emacs while 
> using Gnus. I can reproduce the crash with only two 
> files, a bare bones .gnus and an one-message mbox.
> I included both files at the en of the post.
> The home dir to reproduce the crash looks like this:

> Home/
>     .gnus
>     Mail/
>         Inbox

> Steps to reproduce the crash
> start emacs
> M-x gnus
> No server defined (or somesuch) (Continue? y or n) y RET
> G m RET Inbox RET nnfolder RET
> ;; Now you can see the Inbox group
> RET ;; enter the group and voilá Emacs crashes

This bug was already fixed in HEAD.  But somehow the fix is
not yet installed in RC.  I think this bug is serious enough
to be fixed before the release of 21.3.  If you agree, I'll
install it in RC.

---
Ken'ichi HANDA
handa@m17n.org

PS.  This is the relevant change.

2002-01-02  Richard M. Stallman  <rms@gnu.org>
[...]
	* editfns.c (Fformat): Update thissize from field_width
	based on the actual width, in the string case.

Index: editfns.c
===================================================================
RCS file: /cvs/emacs/src/editfns.c,v
retrieving revision 1.324
retrieving revision 1.325
diff -u -c -r1.324 -r1.325
cvs server: conflicting specifications of output style
*** editfns.c	18 Dec 2001 02:15:53 -0000	1.324
--- editfns.c	2 Jan 2002 19:56:50 -0000	1.325
***************
*** 3217,3222 ****
--- 3217,3223 ----
      if (*format++ == '%')
        {
  	int thissize = 0;
+ 	int actual_width = 0;
  	unsigned char *this_format_start = format - 1;
  	int field_width, precision;
  
***************
*** 3297,3302 ****
--- 3298,3304 ----
  	    if (*format != 's' && *format != 'S')
  	      error ("Format specifier doesn't match argument type");
  	    thissize = CONVERTED_BYTE_SIZE (multibyte, args[n]);
+ 	    actual_width = lisp_string_width (args[n], -1, NULL, NULL);
  	  }
  	/* Would get MPV otherwise, since Lisp_Int's `point' to low memory.  */
  	else if (INTEGERP (args[n]) && *format != 's')
***************
*** 3350,3356 ****
  	    goto string;
  	  }
  
! 	thissize = max (field_width, thissize);
  	total += thissize + 4;
        }
  
--- 3352,3358 ----
  	    goto string;
  	  }
  
! 	thissize += max (0, field_width - actual_width);
  	total += thissize + 4;
        }
  

RC: XML recognition (Re: Gnus crash)

[Karl Eichwalder]

Kenichi Handa <handa@m17n.org> writes:

> I think this bug is serious enough to be fixed before the release of
> 21.3.  If you agree, I'll install it in RC.

Another feature that's badly missing in the RC is recognizing the
encoding of an XML file if the (Emacs) coding tag is missing.  I'd rate
it as a bug if Emacs displays a UTF-8 encoded file as ISO-8859-1.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.gnu.franken.de/ke/                            |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: RC: XML recognition (Re: Gnus crash)

[Jason Rumney]

Karl Eichwalder <keichwa@gmx.net> writes:

> Another feature that's badly missing in the RC is recognizing the
> encoding of an XML file if the (Emacs) coding tag is missing.  I'd rate
> it as a bug if Emacs displays a UTF-8 encoded file as ISO-8859-1.

Recognizing the XML coding tags is a nice new feature, but there are
many nice new features in CVS. If we add all of them to 21.3, it'll
never be released.

Re: RC: XML recognition (Re: Gnus crash)

[Karl Eichwalder]

storm@cua.dk (Kim F. Storm) writes:

> Jason Rumney <jasonr@gnu.org> writes:

>> Recognizing the XML coding tags is a nice new feature, but there are
>> many nice new features in CVS. If we add all of them to 21.3, it'll
>> never be released.

There's only one way out.  Release 21.3 now--it can't be that buggy.
And then be prepared to apply some patches on it and release it as 21.4.
Recognizing XML properly is important for many a lot (new) users.

> Just like 21.4 :-)

CVS HEAD can wait a little bit longer iff the RC branch gets the UTF-8
basics right.  Not every one interested in reasonable UTF-8 support is
prepared to install Emacs from CVS (HEAD).

These are my experiences with users; of course, I'll respect your
experiences, too.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.gnu.franken.de/ke/                            |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: RC: XML recognition (Re: Gnus crash)

[Kim F. Storm]

Jason Rumney <jasonr@gnu.org> writes:

> Karl Eichwalder <keichwa@gmx.net> writes:
> 
> > Another feature that's badly missing in the RC is recognizing the
> > encoding of an XML file if the (Emacs) coding tag is missing.  I'd rate
> > it as a bug if Emacs displays a UTF-8 encoded file as ISO-8859-1.
> 
> Recognizing the XML coding tags is a nice new feature, but there are
> many nice new features in CVS. If we add all of them to 21.3, it'll
> never be released.

Just like 21.4 :-)


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Gnus crash

[Eduardo Muñoz]

Kenichi Handa <handa@m17n.org> writes:

> Thank you for the report.  This bug was already fixed in the
> CVS HEAD by the attached patch.  Eduardo, could you please
> try the attached patch?

I only have emacs-21.2 source here and the patch doesn't
match the file editfns.c. Would be helpfull to download and
build the current CVS version of emacs?


-- 

Eduardo Muñoz

Re: Gnus crash

[Richard Stallman]

    This bug was already fixed in HEAD.  But somehow the fix is
    not yet installed in RC.  I think this bug is serious enough
    to be fixed before the release of 21.3.  If you agree, I'll
    install it in RC.

Please do that.  Thanks.

Re: RC: XML recognition (Re: Gnus crash)

[Richard Stallman]

    Another feature that's badly missing in the RC is recognizing the
    encoding of an XML file if the (Emacs) coding tag is missing.  I'd rate
    it as a bug if Emacs displays a UTF-8 encoded file as ISO-8859-1.

Could you explain what this means?

Re: RC: XML recognition (Re: Gnus crash)

[Karl Eichwalder]

Richard Stallman <rms@gnu.org> writes:

> Could you explain what this means?

. A XML file without encoding information is by definition UTF-8
encoded.  But Emacs from the RC branch does not know about it; Emacs
will open it as a ISO-8859-1 file (at least as long as Emacs was started
in an ISO-8859-1 locale).

. Emacs (RC branch) does not honor the special XML encoding setting
like this:

    <?xml version="1.0" encoding="iso-8859-2"?>

I hope it is clear what I meant.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.gnu.franken.de/ke/                            |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: Gnus crash

[Kenichi Handa]

In article <uel7blace.fsf@terra.es>, "Eduardo =?iso-8859-1?q?Mu=F1oz?=" <emufer@terra.es> writes:
> Kenichi Handa <handa@m17n.org> writes:
>>  Thank you for the report.  This bug was already fixed in the
>>  CVS HEAD by the attached patch.  Eduardo, could you please
>>  try the attached patch?

> I only have emacs-21.2 source here and the patch doesn't
> match the file editfns.c.

Strange.  The patch should be applied to 21.2 source too.
Anyway, I made a new patch for 21.2.  Please try again.

> Would be helpfull to download and build the current CVS
> version of emacs?

It will be helpfull, but please note that it contains lots
of new features that are not yet fully tested.

---
Ken'ichi HANDA
handa@m17n.org


--- editfns.c.orig	Thu Mar 14 04:52:17 2002
+++ editfns.c	Mon Jan 20 09:11:03 2003
@@ -3169,6 +3169,7 @@
     if (*format++ == '%')
       {
 	int thissize = 0;
+	int actual_width = 0;
 	unsigned char *this_format_start = format - 1;
 	int field_width, precision;
 
@@ -3249,6 +3250,7 @@
 	    if (*format != 's' && *format != 'S')
 	      error ("Format specifier doesn't match argument type");
 	    thissize = CONVERTED_BYTE_SIZE (multibyte, args[n]);
+	    actual_width = lisp_string_width (args[n], -1, NULL, NULL);
 	  }
 	/* Would get MPV otherwise, since Lisp_Int's `point' to low memory.  */
 	else if (INTEGERP (args[n]) && *format != 's')
@@ -3302,7 +3304,7 @@
 	    goto string;
 	  }
 
-	thissize = max (field_width, thissize);
+	thissize += max (0, field_width - actual_width);
 	total += thissize + 4;
       }

Re: Gnus crash

[Kenichi Handa]

In article <E18Zh7n-0000o7-00@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
>     This bug was already fixed in HEAD.  But somehow the fix is
>     not yet installed in RC.  I think this bug is serious enough
>     to be fixed before the release of 21.3.  If you agree, I'll
>     install it in RC.

> Please do that.  Thanks.

Done.  But, src/ChangeLog already contained this line.

2003-01-17  Francesco Potortì  <pot@gnu.org>

	* Version 21.3 released.

So, now the top of src/ChangeLog is as below:

2003-01-20  Kenichi Handa  <handa@m17n.org>

	* editfns.c (Fformat): Update thissize from field_width based on
	the actual width, in the string case (back-porting of the
	2002-01-02 change in HEAD).

2003-01-17  Francesco Potortì  <pot@gnu.org>

	* Version 21.3 released.

Does it mean that the fix was too late for 21.3?

---
Ken'ichi HANDA
handa@m17n.org

Re: RC: XML recognition (Re: Gnus crash)

[Richard Stallman]

    . A XML file without encoding information is by definition UTF-8
    encoded.  But Emacs from the RC branch does not know about it; Emacs
    will open it as a ISO-8859-1 file (at least as long as Emacs was started
    in an ISO-8859-1 locale).

I think that counts as a bug.

Ok, let's install this fix in RC.

Re: Gnus crash

[Francesco Potorti`]

>Done.  But, src/ChangeLog already contained this line.
>
>2003-01-17  Francesco Potortì  <pot@gnu.org>
>
>	* Version 21.3 released.

Please do not worry about those entries.  I'll remove them the change
logs, because it turns out that we need one more pretest before 21.3.

Re: Gnus crash

[Kenichi Handa]

In article <E18aY4H-0003nz-00@pot.cnuce.cnr.it>, Francesco Potorti` <pot@gnu.org> writes:
>> Done.  But, src/ChangeLog already contained this line.
>> 
>> 2003-01-17  Francesco Potortì  <pot@gnu.org>
>> 
>> 	* Version 21.3 released.

> Please do not worry about those entries.  I'll remove them the change
> logs, because it turns out that we need one more pretest before 21.3.

I see.

---
Ken'ichi HANDA
handa@m17n.org

Re: Gnus crash

[Richard Stallman]

We need to make another pretest now, which means
those "... released" lines need to be deleted.

Re: Gnus crash

[Eduardo Muñoz]

Kenichi Handa <handa@m17n.org> writes:

> In article <uel7blace.fsf@terra.es>, "Eduardo =?iso-8859-1?q?Mu=F1oz?=" <emufer@terra.es> writes:
[...]
> > I only have emacs-21.2 source here and the patch doesn't
> > match the file editfns.c.
> 
> Strange.  The patch should be applied to 21.2 source too.
> Anyway, I made a new patch for 21.2.  Please try again.

With that patch applyed, emacs work flawlessly with the test
case that I supplied.


> > Would be helpfull to download and build the current CVS
> > version of emacs?
> 
> It will be helpfull, but please note that it contains lots
> of new features that are not yet fully tested.

I built CVS version too. Again, emacs works perfectly with
my test case. I will keep the patch 21.2 version though.

FWIW: OS Windows 2000 Spanish version
      Emacs was built with MSVC++ 6.0


Thanks for your time.


-- 

Eduardo Muñoz

Re: Gnus crash

[Kenichi Handa]

In article <uvg0jcy1n.fsf@terra.es>, "Eduardo =?iso-8859-1?q?Mu=F1oz?=" <emufer@terra.es> writes:
> With that patch applyed, emacs work flawlessly with the test
> case that I supplied.

>>  > Would be helpfull to download and build the current CVS
>>  > version of emacs?
>>  
>>  It will be helpfull, but please note that it contains lots
>>  of new features that are not yet fully tested.

> I built CVS version too. Again, emacs works perfectly with
> my test case. I will keep the patch 21.2 version though.

Thank you for testing it.

---
Ken'ichi HANDA
handa@m17n.org

Re: Gnus crash

[Richard Stallman]

    I built CVS version too. Again, emacs works perfectly with
    my test case. I will keep the patch 21.2 version though.

    FWIW: OS Windows 2000 Spanish version
	  Emacs was built with MSVC++ 6.0

Using Emacs on Windows is taking one step towards freedom, but in
order to reach freedom in using your computer, you need to replace
Windows with a free operating system.

Re: Gnus crash

[Lee Sau Dan]

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:

    Richard> Using Emacs on Windows is taking one step towards
    Richard> freedom, 

And also power!


    Richard> but in order to reach freedom in using your
    Richard> computer, you need to replace Windows with a free
    Richard> operating system.

Again, this applies not only to freedom, but also power!

:P


-- 
Lee Sau Dan                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: Gnus crash

[Richard Stallman]

	Richard> Using Emacs on Windows is taking one step towards
	Richard> freedom, 

    And also power!

You might be right, but I think freedom is more worthy goal than power.

Re: Gnus crash

[Stefan Monnier]

> Debugger entered--Lisp error: (overflow-error)
>   ash(...)
>   message-checksum()
>   message--yank-original-internal(nil)

Sounds like bug#33083


        Stefan

Re: Gnus crash

[Paul Eggert]

Stefan Monnier wrote:
>> Debugger entered--Lisp error: (overflow-error)
>>    ash(...)
>>    message-checksum()
>>    message--yank-original-internal(nil)
> 
> Sounds like bug#33083

Should be fixed now.

Re: Gnus crash

[Juri Linkov]

>>> Debugger entered--Lisp error: (overflow-error)
>>>    ash(...)
>>>    message-checksum()
>>>    message--yank-original-internal(nil)
>>
>> Sounds like bug#33083
>
> Should be fixed now.

Thanks, I confirm that this is now fixed.