bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#3499: marked as done (23.0.94; Assuming strsignal unibyte is wrong a


From: Emacs bug Tracking System
Subject: bug#3499: marked as done (23.0.94; Assuming strsignal unibyte is wrong and leads to Emacs crashes)
Date: Tue, 09 Jun 2009 18:35:05 +0000

Your message dated Tue, 09 Jun 2009 14:28:12 -0400
with message-id <877hzl9s8z.fsf@cyd.mit.edu>
and subject line Re: 23.0.94; Assuming strsignal unibyte is wrong and leads to 
Emacs crashes
has caused the Emacs bug report #3499,
regarding 23.0.94; Assuming strsignal unibyte is wrong and leads to Emacs 
crashes
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
3499: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3499
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems
--- Begin Message --- Subject: 23.0.94; Assuming strsignal unibyte is wrong and leads to Emacs crashes Date: Mon, 08 Jun 2009 21:02:36 +0400 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux)
The `strsignal(SIGNUM)' function from libc returns a pointer to a string
containing a message describing the signal SIGNUM.

Emacs `status_message' function from `src/process.c' attempts to
downcase the initial character of this string to print it in the echo
area:

    signame = strsignal (code);
    string = build_string (signame);
    SSET (string, 0, DOWNCASE (SREF (string, 0)));

As it has already been discussed in bug #778, using SSET/SREF is
incorrect when `string' is multibyte, which is the case for certain
locales like ru_RU.UTF-8. A patch similar to one proposed by Kenichi
Handa for bug #778 fixes this problem, too. The patch is attached.

Attachment: process-status-message-fix-multibyte.diff
Description: Text Data

To reproduce the crash caused by this problem, it's sufficient to call
`recompile' when the compilation buffer has running process inside
(which sometimes occurs when compiling TeX documents, for example). I've
attached the GDB backtrace; the top of the stack gave me the hint that
this problem is nearly the same as in bug #778.

Attachment: gdb-backtrace
Description: Binary data

The rest of this message contains information about my Emacs
installation.

In GNU Emacs 23.0.94.1 (i686-pc-linux-gnu, GTK+ Version 2.14.7) of
 2009-05-29 on blizzard
 
Windowing system distributor `The X.Org Foundation', version
11.0.10503000

configured using `configure '--prefix=/usr' '--host=i686-pc-linux-gnu'
'--mandir=/usr/share/man' '--infodir=/usr/share/info'
'--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib'
'--program-suffix=-emacs-23' '--infodir=/usr/share/info/emacs-23'
'--with-sound' '--with-x' '--with-toolkit-scroll-bars' '--with-gif'
'--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff' '--with-xpm'
'--with-xft' '--without-libotf' '--without-m17n-flt'
'--with-x-toolkit=gtk' '--without-hesiod' '--without-kerberos'
'--without-kerberos5' '--with-gpm' '--with-dbus'
'--build=i686-pc-linux-gnu' 'build_alias=i686-pc-linux-gnu'
'host_alias=i686-pc-linux-gnu' 'CFLAGS=-O2 -march=native -pipe'
'LDFLAGS=-Wl,-O1''

Important settings:
  value of $LC_ALL: 
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: C
  value of $LC_TIME: nil
  value of $LANG: ru_RU.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t
-- 
Happy Hacking.

http://sphinx.net.ru

--- End Message ---
--- Begin Message --- Subject: Re: 23.0.94; Assuming strsignal unibyte is wrong and leads to Emacs crashes Date: Tue, 09 Jun 2009 14:28:12 -0400
> As it has already been discussed in bug #778, using SSET/SREF is
> incorrect when `string' is multibyte, which is the case for certain
> locales like ru_RU.UTF-8. A patch similar to one proposed by Kenichi
> Handa for bug #778 fixes this problem, too. The patch is attached.

Thanks.  This patch looks safe and correct; since it's essentially an
extension of the Bug#778 fix, I've checked it into CVS.

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]