* bug#3499: 23.0.94; Assuming strsignal unibyte is wrong and leads to Emacs crashes
@ 2009-06-08 17:02 ` Dmitry Dzhus
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
0 siblings, 1 reply; 2+ messages in thread
From: Dmitry Dzhus @ 2009-06-08 17:02 UTC (permalink / raw)
To: emacs-pretest-bug; +Cc: dima
[-- 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
む
^ permalink raw reply [flat|nested] 2+ messages in thread
* bug#3499: marked as done (23.0.94; Assuming strsignal unibyte is wrong and leads to Emacs crashes)
2009-06-08 17:02 ` bug#3499: 23.0.94; Assuming strsignal unibyte is wrong and leads to Emacs crashes Dmitry Dzhus
@ 2009-06-09 18:35 ` Emacs bug Tracking System
0 siblings, 0 replies; 2+ messages in thread
From: Emacs bug Tracking System @ 2009-06-09 18:35 UTC (permalink / raw)
To: Chong Yidong
[-- Attachment #1: Type: text/plain, Size: 928 bytes --]
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
[-- Attachment #2: Type: message/rfc822, Size: 11973 bytes --]
[-- Attachment #2.1.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.1.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 #2.1.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 #2.1.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 #2.1.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
む
[-- Attachment #3: Type: message/rfc822, Size: 1503 bytes --]
From: Chong Yidong <cyd@stupidchicken.com>
To: Dmitry Dzhus <dima@sphinx.net.ru>
Cc: 3499-done@emacsbugs.donarmstrong.com
Subject: Re: 23.0.94; Assuming strsignal unibyte is wrong and leads to Emacs crashes
Date: Tue, 09 Jun 2009 14:28:12 -0400
Message-ID: <877hzl9s8z.fsf@cyd.mit.edu>
> 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.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-06-09 18:35 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <877hzl9s8z.fsf@cyd.mit.edu>
2009-06-08 17:02 ` bug#3499: 23.0.94; Assuming strsignal unibyte is wrong and leads to Emacs crashes Dmitry Dzhus
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
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).