From: Dmitry Dzhus <dima@sphinx.net.ru>
To: emacs-pretest-bug@gnu.org
Cc: dima@sphinx.net.ru
Subject: bug#3499: 23.0.94; Assuming strsignal unibyte is wrong and leads to Emacs crashes
Date: Mon, 08 Jun 2009 21:02:36 +0400 [thread overview]
Message-ID: <87skiaacb7.fsf@sphinx.net.ru> (raw)
[-- Attachment #1: Type: text/plain, Size: 658 bytes --]
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.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: process-status-message-fix-multibyte.diff --]
[-- Type: text/x-patch, Size: 811 bytes --]
*** process.c.~1.584.~ 2009-05-02 15:54:45.000000000 +0400
--- process.c 2009-06-08 21:00:15.000000000 +0400
***************
*** 470,476 ****
signame = "unknown";
string = build_string (signame);
string2 = build_string (coredump ? " (core dumped)\n" : "\n");
! SSET (string, 0, DOWNCASE (SREF (string, 0)));
return concat2 (string, string2);
}
else if (EQ (symbol, Qexit))
--- 470,483 ----
signame = "unknown";
string = build_string (signame);
string2 = build_string (coredump ? " (core dumped)\n" : "\n");
!
! {
! int c;
!
! c = STRING_CHAR ((char *) SDATA (string), 0);
! Faset (string, 0, make_number (DOWNCASE (c)));
! }
!
return concat2 (string, string2);
}
else if (EQ (symbol, Qexit))
[-- Attachment #3: Type: text/plain, Size: 332 bytes --]
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 #4: gdb-backtrace --]
[-- Type: application/octet-stream, Size: 4715 bytes --]
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb7351c76 in kill () from /lib/libc.so.6
#2 0x081ca8f8 in abort () at emacs.c:432
#3 0x080ef40f in multibyte_chars_in_text (ptr=0xbfffc92c "\360\243бито\377\377x\311\377\277J\346\a\b\1", nbytes=22) at character.c:622
#4 0x080ef21d in chars_in_text (ptr=0xbfffc920 "Compilation \360\243бито\377\377x\311\377\277J\346\a\b\1", nbytes=22) at character.c:601
#5 0x081fb68a in insert_1 (string=0xbfffc920 "Compilation \360\243бито\377\377x\311\377\277J\346\a\b\1", nbytes=22, inherit=1, prepare=0, before_markers=0) at insdel.c:812
#6 0x0807dd7a in message_dolog (m=0xbfffc920 "Compilation \360\243бито\377\377x\311\377\277J\346\a\b\1", nbytes=22, nlflag=1, multibyte=1) at xdisp.c:7771
#7 0x0807e725 in message3 (m=151705251, nbytes=22, multibyte=1) at xdisp.c:8006
#8 0x08251ad0 in Fmessage (nargs=2, args=0xbfffca54) at editfns.c:3389
#9 0x0825bd15 in Ffuncall (nargs=3, args=0xbfffca50) at eval.c:3026
#10 0x082a0782 in Fbyte_code (bytestr=147516771, vector=147529996, maxdepth=64) at bytecode.c:678
#11 0x0825c5f1 in funcall_lambda (fun=147530276, nargs=3, arg_vector=0xbfffcd64) at eval.c:3232
#12 0x0825c09e in Ffuncall (nargs=4, args=0xbfffcd60) at eval.c:3091
#13 0x082a0782 in Fbyte_code (bytestr=147529107, vector=147530340, maxdepth=32) at bytecode.c:678
#14 0x0825c5f1 in funcall_lambda (fun=147530508, nargs=2, arg_vector=0xbfffd064) at eval.c:3232
#15 0x0825c09e in Ffuncall (nargs=3, args=0xbfffd060) at eval.c:3091
#16 0x0825b5cc in Fapply (nargs=2, args=0xbfffd100) at eval.c:2533
#17 0x0825b987 in apply1 (fn=147480001, arg=152142373) at eval.c:2797
#18 0x082ab447 in read_process_output_call (fun_and_args=152142381) at process.c:5155
#19 0x08259ab8 in internal_condition_case_1 (bfun=0x82ab424 <read_process_output_call>, arg=152142381, handlers=138961257, hfun=0x82ae047 <exec_sentinel_error_handler>) at eval.c:1560
#20 0x082ae22f in exec_sentinel (proc=152339820, reason=145187291) at process.c:6759
#21 0x082ae404 in status_notify (deleting_process=0x9148568) at process.c:6863
#22 0x082a416b in Fdelete_process (process=152339820) at process.c:807
#23 0x0825be0f in Ffuncall (nargs=2, args=0xbfffd3a0) at eval.c:3045
#24 0x082a0782 in Fbyte_code (bytestr=147490395, vector=147491348, maxdepth=16) at bytecode.c:678
#25 0x0825afc6 in Feval (form=147023725) at eval.c:2382
#26 0x08259866 in internal_lisp_condition_case (var=138918089, bodyform=147023725, handlers=147023709) at eval.c:1457
#27 0x082a1458 in Fbyte_code (bytestr=147481355, vector=147492460, maxdepth=96) at bytecode.c:868
#28 0x0825c5f1 in funcall_lambda (fun=147493092, nargs=1, arg_vector=0xbfffdbd8) at eval.c:3232
#29 0x0825c09e in Ffuncall (nargs=2, args=0xbfffdbd4) at eval.c:3091
#30 0x0825b3d8 in Fapply (nargs=2, args=0xbfffdbd4) at eval.c:2478
#31 0x0825bd15 in Ffuncall (nargs=3, args=0xbfffdbd0) at eval.c:3026
#32 0x082a0782 in Fbyte_code (bytestr=147478395, vector=147479332, maxdepth=32) at bytecode.c:678
#33 0x0825c5f1 in funcall_lambda (fun=147479500, nargs=1, arg_vector=0xbfffdf24) at eval.c:3232
#34 0x0825c09e in Ffuncall (nargs=2, args=0xbfffdf20) at eval.c:3091
#35 0x0825775f in Fcall_interactively (function=147344505, record_flag=138918137, keys=138956524) at callint.c:868
#36 0x0825be69 in Ffuncall (nargs=4, args=0xbfffe1e0) at eval.c:3051
#37 0x0825ba26 in call3 (fn=139082745, arg1=147344505, arg2=138918137, arg3=138918089) at eval.c:2875
#38 0x081de8c9 in Fcommand_execute (cmd=147344505, record_flag=138918137, keys=138918089, special=138918089) at keyboard.c:10447
#39 0x081dec46 in Fexecute_extended_command (prefixarg=138918089) at keyboard.c:10560
#40 0x0825be0f in Ffuncall (nargs=2, args=0xbfffe400) at eval.c:3045
#41 0x0825775f in Fcall_interactively (function=138957497, record_flag=138918089, keys=138956524) at callint.c:868
#42 0x0825be69 in Ffuncall (nargs=4, args=0xbfffe6c0) at eval.c:3051
#43 0x0825ba26 in call3 (fn=139082745, arg1=138957497, arg2=138918089, arg3=138918089) at eval.c:2875
#44 0x081de8c9 in Fcommand_execute (cmd=138957497, record_flag=138918089, keys=138918089, special=138918089) at keyboard.c:10447
#45 0x081d0019 in command_loop_1 () at keyboard.c:1901
#46 0x0825998c in internal_condition_case (bfun=0x81ce84f <command_loop_1>, handlers=138961257, hfun=0x81ce220 <cmd_error>) at eval.c:1512
#47 0x081ce5a1 in command_loop_2 () at keyboard.c:1359
#48 0x08259448 in internal_catch (tag=138957281, func=0x81ce57c <command_loop_2>, arg=138918089) at eval.c:1248
#49 0x081ce55a in command_loop () at keyboard.c:1338
#50 0x081cde2c in recursive_edit_1 () at keyboard.c:953
#51 0x081cdf9b in Frecursive_edit () at keyboard.c:1015
#52 0x081cc6fa in main (argc=1, argv=0xbfffef64) at emacs.c:1852
[-- Attachment #5: Type: text/plain, Size: 1375 bytes --]
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
む
next reply other threads:[~2009-06-08 17:02 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <877hzl9s8z.fsf@cyd.mit.edu>
2009-06-08 17:02 ` Dmitry Dzhus [this message]
2009-06-09 18:35 ` bug#3499: marked as done (23.0.94; Assuming strsignal unibyte is wrong and leads to Emacs crashes) Emacs bug Tracking System
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87skiaacb7.fsf@sphinx.net.ru \
--to=dima@sphinx.net.ru \
--cc=3499@emacsbugs.donarmstrong.com \
--cc=emacs-pretest-bug@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).