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

[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

[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

[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

[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

[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)

[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: 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)

[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: 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

[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: 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: 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.