GNU bug report logs -
#7517
24.0.50; repeated crash under Mac OS X
Previous Next
Reported by: emacs user <user.emacs <at> gmail.com>
Date: Mon, 29 Nov 2010 14:30:03 UTC
Severity: normal
Found in version 24.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7517 in the body.
You can then email your comments to 7517 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs.
(Mon, 29 Nov 2010 14:30:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
emacs user <user.emacs <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 29 Nov 2010 14:30:04 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
This crash occurs when I use vm to read my mail, and attempt to edit
an email written in non-English characters. I cannot provide a simple
reproducible example, but it is very easy for me to reproduce this
with my setup and mail files. Am happy to try patches etc. Backtrace
attached.
In GNU Emacs 24.0.50.1 (x86_64-apple-darwin10.4.3, NS apple-appkit-1038.32)
of 2010-11-19 on dhcp-0126683956-1d-ed.client.fas.harvard.edu
Windowing system distributor `Apple', version 10.3.1038
configured using `configure '--with-ns' '--without-x''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: C
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: nil
value of $XMODIFIERS: nil
locale-coding-system: nil
default enable-multibyte-characters: t
Major mode: Fundamental
Minor modes in effect:
delete-selection-mode: t
display-time-mode: t
auto-image-file-mode: t
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
abbrev-mode: t
~ $ cd /usr/local/emacs/trunk/src
/usr/local/emacs/trunk/src $ gdb
/usr/local/emacs/trunk/nextstep/Emacs.app/Cont nts/MacOS/Emacs
GNU gdb 6.3.50-20050815 (Apple version gdb-1472) (Wed Jul 21 10:53:12 UTC 2010)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for
shared libraries ........ ..... done
DISPLAY = :0.0
TERM = xterm
Breakpoint 1 at 0x4189374bb95c7f
Breakpoint 2 at 0x1000be992: file sysdep.c, line 845.
(gdb) run
Starting program:
/usr/local/emacs/trunk/nextstep/Emacs.app/Contents/MacOS/Emacs
Reading symbols for shared libraries
.+++++++++++++.............................................
................................. done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Breakpoint 1, 0x00007fff86da8c7f in abort ()
(gdb) bt full
#0 0x00007fff86da8c7f in abort ()
No symbol table info available.
#1 0x0000000100101ea9 in Fgarbage_collect () at alloc.c:5077
bind = <value temporarily unavailable, due to optimizations>
catch = <value temporarily unavailable, due to optimizations>
handler = <value temporarily unavailable, due to optimizations>
stack_top_variable = 0 '\0'
i = <value temporarily unavailable, due to optimizations>
message_p = 0
total = {4689107254, 1204557, 4337316290, 176147753894,
140734799796272, 4328685322, 40, 4300585072}
count = <value temporarily unavailable, due to optimizations>
t1 = {
tv_sec = 1291039991,
tv_usec = 957606
}
t2 = {
tv_sec = 4328685322,
tv_usec = 1606408508
}
#2 0x000000010011a2ab in Feval (form=4689107254) at eval.c:2242
fun = <value temporarily unavailable, due to optimizations>
val = <value temporarily unavailable, due to optimizations>
original_fun = <value temporarily unavailable, due to optimizations>
original_args = <value temporarily unavailable, due to optimizations>
funcar = <value temporarily unavailable, due to optimizations>
backtrace = {
next = 0x102027f0a,
function = 0x10055b870,
args = 0x10055c518,
nargs = 33566778,
evalargs = 1 '\001',
debug_on_exit = 0 '\0'
}
#3 0x0000000100140f28 in readevalloop (readcharfun=4328685322,
stream=0x7fff70dbff40, sourcenam =4800300321, evalfun=0x100119ff0
<Feval>, printflag=0, unibyte=<value temporarily unavailable, d e to
optimizations>, readfun=4328534074, start=4328534074, end=4328534074)
at lread.c:1737
count1 = 23
c = <value temporarily unavailable, due to optimizations>
val = 4689107254
b = (struct buffer *) 0x0
continue_reading_p = 1
whole_buffer = 0
first_sexp = 0
#4 0x0000000100142915 in Fload (file=4320237433, noerror=4328534074,
nomessage=4328534122, nosu fix=4328534074, must_suffix=4328534122) at
lread.c:1228
stream = (FILE *) 0x7fff70dbff40
fd = 9
count = 12
found = 4801669825
efound = <value temporarily unavailable, due to optimizations>
hist_file_name = 4801669825
newer = 0
compiled = 1
handler = <value temporarily unavailable, due to optimizations>
safe_p = 1
tmp = {4300585720, 7686741539101004111}
version = 23
#5 0x000000010011c15e in do_autoload (fundef=4349060838,
funname=<value temporarily unavailable due to optimizations>) at
eval.c:2203
fun = <value temporarily unavailable, due to optimizations>
#6 0x000000010011ae52 in Ffuncall (nargs=3, args=<value temporarily
unavailable, due to optimiz tions>) at eval.c:3050
fun = <value temporarily unavailable, due to optimizations>
original_fun = 4339766418
funcar = <value temporarily unavailable, due to optimizations>
numargs = 2
val = <value temporarily unavailable, due to optimizations>
backtrace = {
next = 0x7fff5fbfded0,
function = 0x7fff5fbfdd40,
args = 0x7fff5fbfdd48,
nargs = 2,
evalargs = 0 '\0',
debug_on_exit = 0 '\0'
}
internal_args = (Lisp_Object *) 0x7fff5fbfdd48
i = <value temporarily unavailable, due to optimizations>
#7 0x0000000100156b0e in Fbyte_code (bytestr=<value temporarily
unavailable, due to optimizatio s>, vector=<value temporarily
unavailable, due to optimizations>, maxdepth=<value temporarily un
vailable, due to optimizations>) at bytecode.c:679
count = 6
op = <value temporarily unavailable, due to optimizations>
vectorp = (Lisp_Object *) 0x11782b3a0
stack = {
pc = 0x1173921a9 "\210\016E\203\335",
top = 0x7fff5fbfdd50,
bottom = 0x7fff5fbfdd40,
byte_string = 4689404289,
byte_string_start = 0x1173920e0 "\306 \210\307t\030\031\b\203\r",
constants = 4689408917,
next = 0x0
}
top = (Lisp_Object *) 0x7fff5fbfdd40
result = <value temporarily unavailable, due to optimizations>
#8 0x000000010011abdc in funcall_lambda (fun=4679307221, nargs=1,
arg_vector=0x7fff5fbfdf98) at eval.c:3174
val = <value temporarily unavailable, due to optimizations>
syms_left = <value temporarily unavailable, due to optimizations>
next = <value temporarily unavailable, due to optimizations>
i = 1
optional = 1
rest = 0
#9 0x000000010011aed2 in Ffuncall (nargs=2, args=<value temporarily
unavailable, due to optimiz tions>) at eval.c:3047
fun = <value temporarily unavailable, due to optimizations>
original_fun = 4337411042
funcar = <value temporarily unavailable, due to optimizations>
numargs = 1
val = <value temporarily unavailable, due to optimizations>
backtrace = {
next = 0x7fff5fbfe170,
function = 0x7fff5fbfdf90,
args = 0x7fff5fbfdf98,
nargs = 1,
evalargs = 0 '\0',
debug_on_exit = 0 '\0'
}
internal_args = (Lisp_Object *) 0x7fff5fbfdf98
i = <value temporarily unavailable, due to optimizations>
#10 0x000000010011759f in Fcall_interactively (function=4337411042,
record_flag=4328534074, keys 4320148728) at callint.c:849
val = <value temporarily unavailable, due to optimizations>
args = (Lisp_Object *) 0x7fff5fbfdf90
visargs = (Lisp_Object *) 0x7fff5fbfdf70
specs = 4328534074
filter_specs = <value temporarily unavailable, due to optimizations>
teml = 1
up_event = 4328534074
enable = 4328534074
speccount = 3
next_event = 1
prefix_arg = 4328534074
string = <value temporarily unavailable, due to optimizations>
tem = (unsigned char *) 0x1001b53e8 ""
varies = (int *) 0x7fff5fbfdf50
i = 1
j = 1
prompt1 = '\0' <repeats 99 times>
arg_from_tty = 0
key_count = 1
record_then_fail = 0
save_this_command = 4337411042
save_last_command = 4339778850
save_this_original_command = 4337411042
save_real_this_command = 4337411042
#11 0x000000010011b10e in Ffuncall (nargs=4, args=<value temporarily
unavailable, due to optimiz tions>) at eval.c:2996
fun = <value temporarily unavailable, due to optimizations>
original_fun = <value temporarily unavailable, due to optimizations>
funcar = <value temporarily unavailable, due to optimizations>
numargs = 3
val = <value temporarily unavailable, due to optimizations>
backtrace = {
next = 0x0,
function = 0x7fff5fbfe1e0,
args = 0x7fff5fbfe1e8,
nargs = 3,
evalargs = 0 '\0',
debug_on_exit = 0 '\0'
}
internal_args = (Lisp_Object *) 0x7fff5fbfe1e8
i = <value temporarily unavailable, due to optimizations>
#12 0x000000010011b2e6 in call3 (fn=<value temporarily unavailable,
due to optimizations>, arg1= value temporarily unavailable, due to
optimizations>, arg2=<value temporarily unavailable, due t
optimizations>, arg3=<value temporarily unavailable, due to
optimizations>) at eval.c:2820
ret_ungc_val = 4377593632
args = {4328704874, 4337411042, 4328534074, 4328534074}
#13 0x00000001000b4de4 in command_loop_1 () at keyboard.c:1720
cmd = <value temporarily unavailable, due to optimizations>
keybuf = {404, 4797060806, 140734799798992, 4296256866,
4611686018427404288, 4328590042, 4300563296, 7686741539101004111,
140734799799088, 4300585072, 140734799799088, 4797060806, 43005 2440,
4300584952, 140734799799056, 4295665093, 0, 4300586304, 4300586312,
4328534074, 4328534074 4300584952, 140734799799200, 4295665372,
140734799799088, 4797060806, 0, 140734799799136, 14073 799798816, 0}
i = <value temporarily unavailable, due to optimizations>
prev_modiff = 131391
prev_buffer = (struct buffer *) 0x11e044af0
#14 0x00000001001192c5 in internal_condition_case (bfun=0x1000b4930
<command_loop_1>, handlers=4 28590042, hfun=0x1000aa5d0 <cmd_error>)
at eval.c:1460
val = <value temporarily unavailable, due to optimizations>
c = {
tag = 4328534074,
val = 4328534074,
next = 0x7fff5fbfe530,
gcpro = 0x0,
jmp = {5617656, 1, 1606411504, 32767, 1606411184, 32767, 5617496, 1,
5594576, 1, 5596000, 1, 3 993160, 1, 1151554, 1, 530, 0, 8099, 895,
1606411600, 32767, 696960, 1, 5618416, 1, 5618352, 1, , 0, 0, 0, 0,
0, -2033454713, 32767, 0},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 0,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
h = {
handler = 4328590042,
var = 4328534074,
chosen_clause = 4328534122,
tag = 0x7fff5fbfe3d0,
next = 0x0
}
#15 0x00000001000aa187 in command_loop_2 (ignore=<value temporarily
unavailable, due to optimiza ions>) at keyboard.c:1321
val = 4377593632
#16 0x00000001001193c1 in internal_catch (tag=<value temporarily
unavailable, due to optimizatio s>, func=0x1000aa150 <command_loop_2>,
arg=4328534074) at eval.c:1204
c = {
tag = 4328586298,
val = 4328534074,
next = 0x0,
gcpro = 0x0,
jmp = {5617656, 1, 1606411792, 32767, 1606411552, 32767, 5617792, 1,
5594576, 1, 5596000, 1, 34993160, 1, 1151920, 1, 530, 0, 8099, 895,
1606411836, 0, 344, 0, 1606411744, 22, 1454950, 1, 10, 8, 1606411900,
32767, 1606411888, 32767, 9613312, 14, 1796832},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 0,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
#17 0x00000001000aa3d6 in command_loop () at keyboard.c:1300
No locals.
#18 0x00000001000aa84f in recursive_edit_1 () at keyboard.c:923
val = <value temporarily unavailable, due to optimizations>
#19 0x00000001000aa9ef in Frecursive_edit () at keyboard.c:985
count = <value temporarily unavailable, due to optimizations>
buffer = 4328534074
#20 0x00000001000a27c8 in main (argc=1, argv=0x7fff5fbfe840) at emacs.c:1721
dummy = 0
stack_bottom_variable = 0 '\0'
do_initial_setlocale = <value temporarily unavailable, due to
optimizations>
skip_args = 0
rlim = {
rlim_cur = 8720000,
rlim_max = 67104768
}
no_loadup = 0
junk = 0x0
dname_arg = 0x0
dname_arg2 =
"\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\300_\377\177\000\000\000\000\000\000\000\000\000\000\370\005\300_\377\177\000\000\t\000\000\000\t\000\000\000(\352\277_\377\177\000\000`\a\300_\377\177",
'\0' <repeats 17 times>
ch_to_dir = 0x0
Lisp Backtrace:
"vm-retrieve-operable-messages" (0x5fbfdd48)
"vm-edit-message" (0x5fbfdf98)
"call-interactively" (0x5fbfe1e8)
(gdb) xbacktrace full
"vm-retrieve-operable-messages" (0x5fbfdd48)
"vm-edit-message" (0x5fbfdf98)
"call-interactively" (0x5fbfe1e8)
(gdb)
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 17 Dec 2010 11:42:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 7517 <at> debbugs.gnu.org (full text, mbox):
emacs user <user.emacs <at> gmail.com> writes:
> This crash occurs when I use vm to read my mail, and attempt to edit
> an email written in non-English characters. I cannot provide a simple
> reproducible example, but it is very easy for me to reproduce this
> with my setup and mail files. Am happy to try patches etc. Backtrace
> attached.
The backtrace doesn't tell much. Please try couple of things to pin
down the problem:
1. Compile without optimizations (CFLAGS="-g" ./configure; make) and
post another backtrace.
2. Bisect to find the checkin that introduced this problem.
Thanks.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 17 Dec 2010 23:01:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 7517 <at> debbugs.gnu.org (full text, mbox):
thanks for looking into this.
the exact same crash occurs also in 23.2.
when I compile with only -g and start vm, emacs crashes even before
completing the processing of my inbox. here is the bt, although I
have a feeling it is even less useful than previously. again, I'd be
happy to provide additional information if you could guide me through
the needed steps as you did just now with the cflags="-g". E
(gdb) bt full
#0 in malloc_gdb_po_unsafe ()
No symbol table info available.
Lisp Backtrace:
"byte-code"Unsafe to call functions on thread 1: function:
malloc_gdb_po_unsafe on stack
warning: check_safe_call: could not restore current frame
warning: Canceling operation - malloc lock could be held on current thread.
()
"vm-read-attributes"Unsafe to call functions on thread 1: function:
malloc_gdb_po_unsafe on stack
warning: check_safe_call: could not restore current frame
warning: Canceling operation - malloc lock could be held on current thread.
()
"vm-assimilate-new-messages"Unsafe to call functions on thread 1:
function: malloc_gdb_po_unsafe on stack
warning: check_safe_call: could not restore current frame
warning: Canceling operation - malloc lock could be held on current thread.
()
"byte-code"Unsafe to call functions on thread 1: function:
malloc_gdb_po_unsafe on stack
warning: check_safe_call: could not restore current frame
warning: Canceling operation - malloc lock could be held on current thread.
()
"vm"Unsafe to call functions on thread 1: function:
malloc_gdb_po_unsafe on stack
warning: check_safe_call: could not restore current frame
warning: Canceling operation - malloc lock could be held on current thread.
()
"vm-my-open-folder-RMAIL"Unsafe to call functions on thread 1:
function: malloc_gdb_po_unsafe on stack
warning: check_safe_call: could not restore current frame
warning: Canceling operation - malloc lock could be held on current thread.
()
"call-interactively"Unsafe to call functions on thread 1: function:
malloc_gdb_po_unsafe on stack
warning: check_safe_call: could not restore current frame
warning: Canceling operation - malloc lock could be held on current thread.
()
(gdb)
On Fri, Dec 17, 2010 at 1:47 PM, Chong Yidong <> wrote:
> emacs user <> writes:
>
>> This crash occurs when I use vm to read my mail, and attempt to edit
>> an email written in non-English characters. I cannot provide a simple
>> reproducible example, but it is very easy for me to reproduce this
>> with my setup and mail files. Am happy to try patches etc. Backtrace
>> attached.
>
> The backtrace doesn't tell much. Please try couple of things to pin
> down the problem:
>
> 1. Compile without optimizations (CFLAGS="-g" ./configure; make) and
> post another backtrace.
>
> 2. Bisect to find the checkin that introduced this problem.
>
> Thanks.
>
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 17 Dec 2010 23:36:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 7517 <at> debbugs.gnu.org (full text, mbox):
and here is the backtrace for emacs-23.2 for the original bug. this
is with optimization. should I try without?
$ gdb /usr/local/emacs-23.2/nextstep/Emacs-23.2.app/Contents/MacOS/Emacs
GNU gdb 6.3.50-20050815 (Apple version gdb-1472) (Wed Jul 21 10:53:12 UTC 2010)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for
shared libraries ......... done
(gdb) run
Starting program:
/usr/local/emacs-23.2/nextstep/Emacs-23.2.app/Contents/MacOS/Emacs
Reading symbols for shared libraries
.++++++++................................................................................
done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
2010-12-17 18:39:00.121 Emacs[36221:a0f] *** Assertion failure in
-[EmacsWindow setTitle:],
/SourceCache/AppKit/AppKit-1038.35/AppKit.subproj/NSWindow.m:2036
2010-12-17 18:39:00.124 Emacs[36221:a0f] An uncaught exception was raised
2010-12-17 18:39:00.124 Emacs[36221:a0f] Invalid parameter not
satisfying: aString != nil
2010-12-17 18:39:00.128 Emacs[36221:a0f] *** Terminating app due to
uncaught exception 'NSInternalInconsistencyException', reason:
'Invalid parameter not satisfying: aString != nil'
*** Call stack at first throw:
(
0 CoreFoundation 0x00007fff842277b4
__exceptionPreprocess + 180
1 libobjc.A.dylib 0x00007fff83f070f3
objc_exception_throw + 45
2 CoreFoundation 0x00007fff842275d7
+[NSException raise:format:arguments:] + 103
3 Foundation 0x00007fff8394687a
-[NSAssertionHandler
handleFailureInMethod:object:file:lineNumber:description:] + 198
4 AppKit 0x00007fff8052ab98 -[NSWindow
setTitle:] + 141
5 Emacs 0x000000010017b99c
ns_set_name_as_filename + 844
6 Emacs 0x0000000100037cd1
prepare_menu_bars + 721
7 Emacs 0x000000010004150a
redisplay_internal + 3146
8 Emacs 0x0000000100041e5f
redisplay_preserve_echo_area + 47
9 Emacs 0x00000001000058a1 Fredisplay + 225
10 Emacs 0x00000001001092c2 Ffuncall + 1218
11 Emacs 0x0000000100145abe Fbyte_code + 6814
12 Emacs 0x0000000100108c0c funcall_lambda + 588
13 Emacs 0x0000000100109052 Ffuncall + 594
14 Emacs 0x0000000100145abe Fbyte_code + 6814
15 Emacs 0x0000000100108c0c funcall_lambda + 588
16 Emacs 0x0000000100109052 Ffuncall + 594
17 Emacs 0x000000010010acb5 Fapply + 325
18 Emacs 0x000000010010935b Ffuncall + 1371
19 Emacs 0x0000000100145abe Fbyte_code + 6814
20 Emacs 0x0000000100108674 Feval + 1476
21 Emacs 0x000000010010b1e6
internal_lisp_condition_case + 502
22 Emacs 0x0000000100144b25 Fbyte_code + 2821
23 Emacs 0x0000000100108c0c funcall_lambda + 588
24 Emacs 0x0000000100109052 Ffuncall + 594
25 Emacs 0x000000010010a79e call1 + 30
26 Emacs 0x0000000100099695 timer_check + 1013
27 Emacs 0x000000010014dd28
wait_reading_process_output + 3816
28 Emacs 0x000000010014f4a8
Faccept_process_output + 312
29 Emacs 0x0000000100109283 Ffuncall + 1155
30 Emacs 0x0000000100145abe Fbyte_code + 6814
31 Emacs 0x0000000100108674 Feval + 1476
32 Emacs 0x000000010010b1e6
internal_lisp_condition_case + 502
33 Emacs 0x0000000100144b25 Fbyte_code + 2821
34 Emacs 0x0000000100108c0c funcall_lambda + 588
35 Emacs 0x0000000100109052 Ffuncall + 594
36 Emacs 0x0000000100145abe Fbyte_code + 6814
37 Emacs 0x0000000100108c0c funcall_lambda + 588
38 Emacs 0x0000000100109052 Ffuncall + 594
39 Emacs 0x000000010010a9af
run_hook_with_args + 271
40 Emacs 0x000000010010ab46 Frun_hooks + 54
41 Emacs 0x000000010010935b Ffuncall + 1371
42 Emacs 0x000000010010a79e call1 + 30
43 Emacs 0x0000000100107727
internal_condition_case + 327
44 Emacs 0x000000010009a9b0 safe_run_hooks + 80
45 Emacs 0x00000001000a3903
command_loop_1 + 1315
46 Emacs 0x0000000100107727
internal_condition_case + 327
47 Emacs 0x000000010009aa07 command_loop_2 + 55
48 Emacs 0x0000000100107830 internal_catch + 224
49 Emacs 0x000000010009b496 command_loop + 182
50 Emacs 0x000000010009b8ff
recursive_edit_1 + 159
51 Emacs 0x000000010009ba9f
Frecursive_edit + 287
52 Emacs 0x0000000100091087 main + 3447
53 Emacs 0x00000001000020b4 start + 52
54 ??? 0x0000000000000001 0x0 + 1
)
terminate called after throwing an instance of 'NSException'
Program received signal SIGABRT, Aborted.
0x00007fff84003616 in __kill ()
(gdb) bt full
#0 0x00007fff84003616 in __kill ()
No symbol table info available.
#1 0x00007fff840a3cca in abort ()
No symbol table info available.
#2 0x00007fff888e15d2 in __gnu_cxx::__verbose_terminate_handler ()
No symbol table info available.
#3 0x00007fff83f0ad29 in _objc_terminate ()
No symbol table info available.
#4 0x00007fff888dfae1 in __cxxabiv1::__terminate ()
No symbol table info available.
#5 0x00007fff888dfb16 in std::terminate ()
No symbol table info available.
#6 0x00007fff888dfbfc in __cxa_throw ()
No symbol table info available.
#7 0x00007fff83f07192 in objc_exception_throw ()
No symbol table info available.
#8 0x00007fff842275d7 in +[NSException raise:format:arguments:] ()
No symbol table info available.
#9 0x00007fff8394687a in -[NSAssertionHandler
handleFailureInMethod:object:file:lineNumber:description:] ()
No symbol table info available.
#10 0x00007fff8052ab98 in -[NSWindow setTitle:] ()
No symbol table info available.
#11 0x000000010017b99c in ns_set_name_as_filename (f=0x100753e70) at nsfns.m:666
str = (NSString *) 0x0
view = (NSView *) 0x100ae85f0
name = 4802201153
buf = <value temporarily unavailable, due to optimizations>
title = <value temporarily unavailable, due to optimizations>
#12 0x0000000100037cd1 in prepare_menu_bars () at xdisp.c:9475
tail = <value temporarily unavailable, due to optimizations>
fmt = <value temporarily unavailable, due to optimizations>
len = 0
title = 0x100a0c4d0 ""
it = {
window = 4797980437,
w = 0x11dfb5f10,
f = 0x100753e70,
method = GET_FROM_BUFFER,
stop_charpos = 0,
end_charpos = 0,
s = 0x0,
string_nchars = 0,
region_beg_charpos = -1,
region_end_charpos = -1,
redisplay_end_trigger_charpos = 0,
multibyte_p = 1,
header_line_p = 0,
string_from_display_prop_p = 0,
ellipsis_p = 0,
avoid_cursor_p = 0,
dp = 0x116916eb0,
dpvec = 0x0,
dpend = 0x0,
dpvec_char_len = 0,
dpvec_face_id = 0,
saved_face_id = 0,
ctl_chars = {0 <repeats 16 times>},
start = {
pos = {
charpos = 0,
bytepos = 0
},
overlay_string_index = 0,
string_pos = {
charpos = 0,
bytepos = 0
},
dpvec_index = 0
},
current = {
pos = {
charpos = 0,
bytepos = 0
},
overlay_string_index = -1,
string_pos = {
charpos = -1,
bytepos = -1
},
dpvec_index = -1
},
n_overlay_strings = 0,
overlay_strings = {0 <repeats 16 times>},
string_overlays = {0 <repeats 16 times>},
string = 4320133130,
from_overlay = 0,
stack = {{
string = 0,
string_nchars = 0,
end_charpos = 0,
stop_charpos = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
lookback = 0,
nglyphs = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
face_id = 0,
u = {
image = {
object = 0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
image_id = 0
},
comp = {
object = 0
},
stretch = {
object = 0
}
},
position = {
charpos = 0,
bytepos = 0
},
current = {
pos = {
charpos = 0,
bytepos = 0
},
overlay_string_index = 0,
string_pos = {
charpos = 0,
bytepos = 0
},
dpvec_index = 0
},
from_overlay = 0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
multibyte_p = 0,
string_from_display_prop_p = 0,
display_ellipsis_p = 0,
avoid_cursor_p = 0,
line_wrap = TRUNCATE,
voffset = 0,
space_width = 0,
font_height = 0
}, {
string = 0,
string_nchars = 0,
end_charpos = 0,
stop_charpos = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
lookback = 0,
nglyphs = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
face_id = 0,
u = {
image = {
object = 0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
image_id = 0
},
comp = {
object = 0
},
stretch = {
object = 0
}
},
position = {
charpos = 0,
bytepos = 0
},
current = {
pos = {
charpos = 0,
bytepos = 0
},
overlay_string_index = 0,
string_pos = {
charpos = 0,
bytepos = 0
},
dpvec_index = 0
},
from_overlay = 0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
multibyte_p = 0,
string_from_display_prop_p = 0,
display_ellipsis_p = 0,
avoid_cursor_p = 0,
line_wrap = TRUNCATE,
voffset = 0,
space_width = 0,
font_height = 0
}, {
string = 0,
string_nchars = 0,
end_charpos = 0,
stop_charpos = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
lookback = 0,
nglyphs = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
face_id = 0,
u = {
image = {
object = 0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
image_id = 0
},
comp = {
object = 0
},
stretch = {
object = 0
}
},
position = {
charpos = 0,
bytepos = 0
},
current = {
pos = {
charpos = 0,
bytepos = 0
},
overlay_string_index = 0,
string_pos = {
charpos = 0,
bytepos = 0
},
dpvec_index = 0
},
from_overlay = 0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
multibyte_p = 0,
string_from_display_prop_p = 0,
display_ellipsis_p = 0,
avoid_cursor_p = 0,
line_wrap = TRUNCATE,
voffset = 0,
space_width = 0,
font_height = 0
}, {
string = 0,
string_nchars = 0,
end_charpos = 0,
stop_charpos = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
lookback = 0,
nglyphs = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
face_id = 0,
u = {
image = {
object = 0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
image_id = 0
},
comp = {
object = 0
},
stretch = {
object = 0
}
},
position = {
charpos = 0,
bytepos = 0
},
current = {
pos = {
charpos = 0,
bytepos = 0
},
overlay_string_index = 0,
string_pos = {
charpos = 0,
bytepos = 0
},
dpvec_index = 0
},
from_overlay = 0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
multibyte_p = 0,
string_from_display_prop_p = 0,
display_ellipsis_p = 0,
avoid_cursor_p = 0,
line_wrap = TRUNCATE,
voffset = 0,
space_width = 0,
font_height = 0
}},
sp = 0,
selective = 0,
what = IT_CHARACTER,
face_id = 0,
selective_display_ellipsis_p = 1,
ctl_arrow_p = 1,
face_box_p = 0,
start_of_box_run_p = 0,
end_of_box_run_p = 0,
overlay_strings_at_end_processed_p = 0,
ignore_overlay_strings_at_pos_p = 0,
glyph_not_available_p = 0,
starts_in_middle_of_char_p = 0,
face_before_selective_p = 0,
constrain_row_ascent_descent_p = 0,
line_wrap = WINDOW_WRAP,
base_face_id = 0,
c = 0,
len = 0,
cmp_it = {
stop_pos = 0,
id = -1,
ch = 0,
lookback = 0,
nglyphs = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
char_to_display = 0,
image_id = 0,
slice = {
x = 4320133130,
y = 4320133130,
width = 4320133130,
height = 4320133130
},
space_width = 4320133130,
voffset = 0,
tab_width = 8,
font_height = 4320133130,
object = 0,
position = {
charpos = 0,
bytepos = 0
},
truncation_pixel_width = 0,
continuation_pixel_width = 0,
first_visible_x = 0,
last_visible_x = 1080,
last_visible_y = 696,
extra_line_spacing = 0,
max_extra_line_spacing = 0,
override_ascent = -1,
override_descent = 0,
override_boff = 0,
glyph_row = 0x0,
area = TEXT_AREA,
nglyphs = 0,
pixel_width = 0,
ascent = 0,
descent = 0,
max_ascent = 0,
max_descent = 0,
phys_ascent = 0,
phys_descent = 0,
max_phys_ascent = 0,
max_phys_descent = 0,
current_x = 0,
continuation_lines_width = 0,
current_y = 0,
first_vpos = 0,
vpos = 0,
hpos = 0,
left_user_fringe_bitmap = 0,
right_user_fringe_bitmap = 0,
left_user_fringe_face_id = 0,
right_user_fringe_face_id = 0
}
f = <value temporarily unavailable, due to optimizations>
frame = Cannot access memory at address 0x0
(gdb)
On Fri, Dec 17, 2010 at 1:47 PM, Chong Yidong <cyd <at> stupidchicken.com> wrote:
> emacs user <user.emacs <at> gmail.com> writes:
>
>> This crash occurs when I use vm to read my mail, and attempt to edit
>> an email written in non-English characters. I cannot provide a simple
>> reproducible example, but it is very easy for me to reproduce this
>> with my setup and mail files. Am happy to try patches etc. Backtrace
>> attached.
>
> The backtrace doesn't tell much. Please try couple of things to pin
> down the problem:
>
> 1. Compile without optimizations (CFLAGS="-g" ./configure; make) and
> post another backtrace.
>
> 2. Bisect to find the checkin that introduced this problem.
>
> Thanks.
>
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Sun, 26 Dec 2010 18:37:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 7517 <at> debbugs.gnu.org (full text, mbox):
one more piece of information which may be relevant: It seems that
emacs is trying to set the frame title to reflect the text, subject
and sender of the vm message which I am attempting to edit. the text
of the header contains characters such as \362 \351 \370 etc. Does
this help?
> On Fri, Dec 17, 2010 at 1:47 PM, Chong Yidong <cyd <at> stupidchicken.com> wrote:
>> emacs user <user.emacs <at> gmail.com> writes:
>>
>>> This crash occurs when I use vm to read my mail, and attempt to edit
>>> an email written in non-English characters. I cannot provide a simple
>>> reproducible example, but it is very easy for me to reproduce this
>>> with my setup and mail files. Am happy to try patches etc. Backtrace
>>> attached.
>>
>> The backtrace doesn't tell much. Please try couple of things to pin
>> down the problem:
>>
>> 1. Compile without optimizations (CFLAGS="-g" ./configure; make) and
>> post another backtrace.
>>
>> 2. Bisect to find the checkin that introduced this problem.
>>
>> Thanks.
>>
>
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Wed, 29 Dec 2010 04:23:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 7517 <at> debbugs.gnu.org (full text, mbox):
In Bug#7517, it appears that the NS port is not setting the frame title
correctly under some circumstances. Could anyone on Mac OS take a look?
Probably there's a mistake in string conversion in the argument to
setTitle somewhere in src/nsterm.m.
emacs user <user.emacs <at> gmail.com> writes:
> one more piece of information which may be relevant: It seems that
> emacs is trying to set the frame title to reflect the text, subject
> and sender of the vm message which I am attempting to edit. the text
> of the header contains characters such as \362 \351 \370 etc. Does
> this help?
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Wed, 29 Dec 2010 11:53:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 7517 <at> debbugs.gnu.org (full text, mbox):
We need to know the locale used. \362 \351 \370 doesn't say anything as we
don't know the character set. FWIW, I have no problem with frame titles that
contain non-ascii characters. However, the NS port doesn't update the frame
parameter title properly, but it doesn't crash.
Is it possible that vm can try to put non-UTF8 characters in to the title?
Jan D.
Chong Yidong skrev 2010-12-29 05.29:
> In Bug#7517, it appears that the NS port is not setting the frame title
> correctly under some circumstances. Could anyone on Mac OS take a look?
> Probably there's a mistake in string conversion in the argument to
> setTitle somewhere in src/nsterm.m.
>
>
> emacs user<user.emacs <at> gmail.com> writes:
>
>> one more piece of information which may be relevant: It seems that
>> emacs is trying to set the frame title to reflect the text, subject
>> and sender of the vm message which I am attempting to edit. the text
>> of the header contains characters such as \362 \351 \370 etc. Does
>> this help?
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Wed, 29 Dec 2010 12:15:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 7517 <at> debbugs.gnu.org (full text, mbox):
Jan Djärv skrev 2010-12-29 12.59:
> Is it possible that vm can try to put non-UTF8 characters in to the title?
>
What I see is that the X code does ENCODE_UTF_8, and W32 does ENCODE_SYSTEM
before passing the string to the platform title setting function. NS does
nothing. Can this be the problem?
Jan D.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Wed, 29 Dec 2010 15:36:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 7517 <at> debbugs.gnu.org (full text, mbox):
> What I see is that the X code does ENCODE_UTF_8, and W32 does ENCODE_SYSTEM
> before passing the string to the platform title setting function. NS does
> nothing. Can this be the problem?
Possibly. Maybe ENCODE_UTF_8 would fix the problem.
Stefan
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Wed, 29 Dec 2010 16:00:03 GMT)
Full text and
rfc822 format available.
Message #32 received at 7517 <at> debbugs.gnu.org (full text, mbox):
regarding the locale, I am not sure what that means exactly, but these
were originally hebrew characters that were somehow not correctly
stored by vm/emacs and turned into the characters I mentioned. I hope
to be able to produce a detailed bug report on that problem as well...
hope this helps
On Wed, Dec 29, 2010 at 5:41 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>> What I see is that the X code does ENCODE_UTF_8, and W32 does ENCODE_SYSTEM
>> before passing the string to the platform title setting function. NS does
>> nothing. Can this be the problem?
>
> Possibly. Maybe ENCODE_UTF_8 would fix the problem.
>
>
> Stefan
>
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Thu, 30 Dec 2010 11:29:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 7517 <at> debbugs.gnu.org (full text, mbox):
emacs user skrev 2010-12-29 17.06:
> regarding the locale, I am not sure what that means exactly, but these
> were originally hebrew characters that were somehow not correctly
> stored by vm/emacs and turned into the characters I mentioned. I hope
> to be able to produce a detailed bug report on that problem as well...
> hope this helps
Locale in this context means the character set and language environment you
are using.
>
> On Wed, Dec 29, 2010 at 5:41 PM, Stefan Monnier
> <monnier <at> iro.umontreal.ca> wrote:
>>> What I see is that the X code does ENCODE_UTF_8, and W32 does ENCODE_SYSTEM
>>> before passing the string to the platform title setting function. NS does
>>> nothing. Can this be the problem?
>>
>> Possibly. Maybe ENCODE_UTF_8 would fix the problem.
>>
Ok, I added ENCODE_UTF_8. Can you tru the latest trunk and see if this fixes it?
Thanks,
Jan D.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Thu, 30 Dec 2010 14:14:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 7517 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
sorry, still crashes with the same error message, I think, see
attached. best, E
On Thu, Dec 30, 2010 at 1:35 PM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:
>
>
> emacs user skrev 2010-12-29 17.06:
>>
>> regarding the locale, I am not sure what that means exactly, but these
>> were originally hebrew characters that were somehow not correctly
>> stored by vm/emacs and turned into the characters I mentioned. I hope
>> to be able to produce a detailed bug report on that problem as well...
>> hope this helps
>
> Locale in this context means the character set and language environment you
> are using.
>
>>
>> On Wed, Dec 29, 2010 at 5:41 PM, Stefan Monnier
>> <monnier <at> iro.umontreal.ca> wrote:
>>>>
>>>> What I see is that the X code does ENCODE_UTF_8, and W32 does
>>>> ENCODE_SYSTEM
>>>> before passing the string to the platform title setting function. NS
>>>> does
>>>> nothing. Can this be the problem?
>>>
>>> Possibly. Maybe ENCODE_UTF_8 would fix the problem.
>>>
>
> Ok, I added ENCODE_UTF_8. Can you tru the latest trunk and see if this
> fixes it?
>
> Thanks,
>
> Jan D.
>
[t (application/octet-stream, attachment)]
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Thu, 30 Dec 2010 21:56:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 7517 <at> debbugs.gnu.org (full text, mbox):
emacs user skrev 2010-12-30 15.20:
> sorry, still crashes with the same error message, I think, see
> attached. best, E
>
Ok, it was a long shot. Can you in gdb:
(gdb) fr 10
(gdb) p name
(gdb) xstring
?
Thanks,
Jan D.
>
>
> On Thu, Dec 30, 2010 at 1:35 PM, Jan Djärv<jan.h.d <at> swipnet.se> wrote:
>>
>>
>> emacs user skrev 2010-12-29 17.06:
>>>
>>> regarding the locale, I am not sure what that means exactly, but these
>>> were originally hebrew characters that were somehow not correctly
>>> stored by vm/emacs and turned into the characters I mentioned. I hope
>>> to be able to produce a detailed bug report on that problem as well...
>>> hope this helps
>>
>> Locale in this context means the character set and language environment you
>> are using.
>>
>>>
>>> On Wed, Dec 29, 2010 at 5:41 PM, Stefan Monnier
>>> <monnier <at> iro.umontreal.ca> wrote:
>>>>>
>>>>> What I see is that the X code does ENCODE_UTF_8, and W32 does
>>>>> ENCODE_SYSTEM
>>>>> before passing the string to the platform title setting function. NS
>>>>> does
>>>>> nothing. Can this be the problem?
>>>>
>>>> Possibly. Maybe ENCODE_UTF_8 would fix the problem.
>>>>
>>
>> Ok, I added ENCODE_UTF_8. Can you tru the latest trunk and see if this
>> fixes it?
>>
>> Thanks,
>>
>> Jan D.
>>
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 31 Dec 2010 06:05:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 7517 <at> debbugs.gnu.org (full text, mbox):
(gdb) p name
$1 = 4802696161
(gdb) xstring
$2 = (struct Lisp_String *) 0x11e4353e0
"edit of \362\351\370\343 \351\345\342\341's note re: \371\345\354\347
\343\345\340\370 \340\354\367\350\370\345\360\351: IMG_0373, IMG_0436,
IMG_0456, IMG_0545, IMG_0575, IMG_0596, IMG_0636, IMG_0641, IMG_0744,
IMG_0745, IMG_0906, IMG_0925, IMG_1025, IMG_1038, IMG_1121"
(gdb)
On Fri, Dec 31, 2010 at 12:02 AM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:
>
>
> emacs user skrev 2010-12-30 15.20:
>>
>> sorry, still crashes with the same error message, I think, see
>> attached. best, E
>>
>
> Ok, it was a long shot. Can you in gdb:
>
> (gdb) fr 10
> (gdb) p name
> (gdb) xstring
>
> ?
>
> Thanks,
>
> Jan D.
>
>>
>>
>> On Thu, Dec 30, 2010 at 1:35 PM, Jan Djärv<jan.h.d <at> swipnet.se> wrote:
>>>
>>>
>>> emacs user skrev 2010-12-29 17.06:
>>>>
>>>> regarding the locale, I am not sure what that means exactly, but these
>>>> were originally hebrew characters that were somehow not correctly
>>>> stored by vm/emacs and turned into the characters I mentioned. I hope
>>>> to be able to produce a detailed bug report on that problem as well...
>>>> hope this helps
>>>
>>> Locale in this context means the character set and language environment
>>> you
>>> are using.
>>>
>>>>
>>>> On Wed, Dec 29, 2010 at 5:41 PM, Stefan Monnier
>>>> <monnier <at> iro.umontreal.ca> wrote:
>>>>>>
>>>>>> What I see is that the X code does ENCODE_UTF_8, and W32 does
>>>>>> ENCODE_SYSTEM
>>>>>> before passing the string to the platform title setting function. NS
>>>>>> does
>>>>>> nothing. Can this be the problem?
>>>>>
>>>>> Possibly. Maybe ENCODE_UTF_8 would fix the problem.
>>>>>
>>>
>>> Ok, I added ENCODE_UTF_8. Can you tru the latest trunk and see if this
>>> fixes it?
>>>
>>> Thanks,
>>>
>>> Jan D.
>>>
>
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 31 Dec 2010 06:06:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 7517 <at> debbugs.gnu.org (full text, mbox):
I forgot to include the first part of this:
(gdb) fr 10
#10 0x000000010019fd3c in ns_set_name_as_filename (f=0x100b418e0) at nsfns.m:655
655 [[view window] setTitle: str];
Current language: auto; currently objective-c
(gdb) p name
$1 = 4802696161
(gdb) xstring
$2 = (struct Lisp_String *) 0x11e4353e0
"edit of \362\351\370\343 \351\345\342\341's note re: \371\345\354\347
\343\345\340\370 \340\354\367\350\370\345\360\351: IMG_0373, IMG_0436,
IMG_0456, IMG_0545, IMG_0575, IMG_0596, IMG_0636, IMG_0641, IMG_0744,
IMG_0745, IMG_0906, IMG_0925, IMG_1025, IMG_1038, IMG_1121"
On Fri, Dec 31, 2010 at 12:02 AM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:
>
>
> emacs user skrev 2010-12-30 15.20:
>>
>> sorry, still crashes with the same error message, I think, see
>> attached. best, E
>>
>
> Ok, it was a long shot. Can you in gdb:
>
> (gdb) fr 10
> (gdb) p name
> (gdb) xstring
>
> ?
>
> Thanks,
>
> Jan D.
>
>>
>>
>> On Thu, Dec 30, 2010 at 1:35 PM, Jan Djärv<jan.h.d <at> swipnet.se> wrote:
>>>
>>>
>>> emacs user skrev 2010-12-29 17.06:
>>>>
>>>> regarding the locale, I am not sure what that means exactly, but these
>>>> were originally hebrew characters that were somehow not correctly
>>>> stored by vm/emacs and turned into the characters I mentioned. I hope
>>>> to be able to produce a detailed bug report on that problem as well...
>>>> hope this helps
>>>
>>> Locale in this context means the character set and language environment
>>> you
>>> are using.
>>>
>>>>
>>>> On Wed, Dec 29, 2010 at 5:41 PM, Stefan Monnier
>>>> <monnier <at> iro.umontreal.ca> wrote:
>>>>>>
>>>>>> What I see is that the X code does ENCODE_UTF_8, and W32 does
>>>>>> ENCODE_SYSTEM
>>>>>> before passing the string to the platform title setting function. NS
>>>>>> does
>>>>>> nothing. Can this be the problem?
>>>>>
>>>>> Possibly. Maybe ENCODE_UTF_8 would fix the problem.
>>>>>
>>>
>>> Ok, I added ENCODE_UTF_8. Can you tru the latest trunk and see if this
>>> fixes it?
>>>
>>> Thanks,
>>>
>>> Jan D.
>>>
>
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 31 Dec 2010 08:10:03 GMT)
Full text and
rfc822 format available.
Message #50 received at 7517 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 31 Dec 2010 08:12:23 +0200
> From: emacs user <user.emacs <at> gmail.com>
> Cc: 7517 <at> debbugs.gnu.org, emacs-devel <at> gnu.org,
> Chong Yidong <cyd <at> stupidchicken.com>
>
> I forgot to include the first part of this:
>
> (gdb) fr 10
> #10 0x000000010019fd3c in ns_set_name_as_filename (f=0x100b418e0) at nsfns.m:655
> 655 [[view window] setTitle: str];
> Current language: auto; currently objective-c
> (gdb) p name
> $1 = 4802696161
> (gdb) xstring
> $2 = (struct Lisp_String *) 0x11e4353e0
> "edit of \362\351\370\343 \351\345\342\341's note re: \371\345\354\347
> \343\345\340\370 \340\354\367\350\370\345\360\351: IMG_0373, IMG_0436,
> IMG_0456, IMG_0545, IMG_0575, IMG_0596, IMG_0636, IMG_0641, IMG_0744,
> IMG_0745, IMG_0906, IMG_0925, IMG_1025, IMG_1038, IMG_1121"
What was this supposed to say in Hebrew? You said a few messages
back that these were originally Hebrew characters; can you show the
original Hebrew text of this?
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 31 Dec 2010 10:44:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 7517 <at> debbugs.gnu.org (full text, mbox):
emacs user skrev 2010-12-31 07.12:
> I forgot to include the first part of this:
>
> (gdb) fr 10
> #10 0x000000010019fd3c in ns_set_name_as_filename (f=0x100b418e0) at nsfns.m:655
> 655 [[view window] setTitle: str];
> Current language: auto; currently objective-c
> (gdb) p name
> $1 = 4802696161
> (gdb) xstring
> $2 = (struct Lisp_String *) 0x11e4353e0
> "edit of \362\351\370\343 \351\345\342\341's note re: \371\345\354\347
> \343\345\340\370 \340\354\367\350\370\345\360\351: IMG_0373, IMG_0436,
> IMG_0456, IMG_0545, IMG_0575, IMG_0596, IMG_0636, IMG_0641, IMG_0744,
> IMG_0745, IMG_0906, IMG_0925, IMG_1025, IMG_1038, IMG_1121"
>
>
That is no utf-8 string (looks like a unibyte string), so the fact that str is
nil is expected. Is this a filename? In that case there is a bug here,
filename coding isn't used.
Can you in a shell do:
% env | grep LANG
and
% env | grep LC_
Thanks,
Jan D.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 31 Dec 2010 11:10:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 7517 <at> debbugs.gnu.org (full text, mbox):
if I forward the message to gmail, I can read the hebrew characters:
--------- Forwarded message ----------
From: "עירד xx" <xxx> (I censored part of the name and the email)
Subject: שולח דואר אלקטרוני: IMG_0373, IMG_0436, IMG_0456, IMG_0545,
IMG_0575, IMG_0596, IMG_0636, IMG_0641, IMG_0744, IMG_0745, IMG_0906,
IMG_0925, IMG_1025, IMG_1038, IMG_1121
..על קצה המזלג
also,
$ env | grep LANG
$ env | grep LC_
LC_COLLATE=C
$
On Fri, Dec 31, 2010 at 10:18 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Fri, 31 Dec 2010 08:12:23 +0200
>> From: emacs user <user.emacs <at> gmail.com>
>> Cc: 7517 <at> debbugs.gnu.org, emacs-devel <at> gnu.org,
>> Chong Yidong <cyd <at> stupidchicken.com>
>>
>> I forgot to include the first part of this:
>>
>> (gdb) fr 10
>> #10 0x000000010019fd3c in ns_set_name_as_filename (f=0x100b418e0) at nsfns.m:655
>> 655 [[view window] setTitle: str];
>> Current language: auto; currently objective-c
>> (gdb) p name
>> $1 = 4802696161
>> (gdb) xstring
>> $2 = (struct Lisp_String *) 0x11e4353e0
>> "edit of \362\351\370\343 \351\345\342\341's note re: \371\345\354\347
>> \343\345\340\370 \340\354\367\350\370\345\360\351: IMG_0373, IMG_0436,
>> IMG_0456, IMG_0545, IMG_0575, IMG_0596, IMG_0636, IMG_0641, IMG_0744,
>> IMG_0745, IMG_0906, IMG_0925, IMG_1025, IMG_1038, IMG_1121"
>
> What was this supposed to say in Hebrew? You said a few messages
> back that these were originally Hebrew characters; can you show the
> original Hebrew text of this?
>
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 31 Dec 2010 11:17:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 7517 <at> debbugs.gnu.org (full text, mbox):
On further thought, it isn't a filename, that would start with / (assuming
buffer filenames are always absolute). In that case, the question is how a
buffer name can be a unibyte string?
Jan D.
Jan Djärv skrev 2010-12-31 11.49:
>
>
> emacs user skrev 2010-12-31 07.12:
>> I forgot to include the first part of this:
>>
>> (gdb) fr 10
>> #10 0x000000010019fd3c in ns_set_name_as_filename (f=0x100b418e0) at
>> nsfns.m:655
>> 655 [[view window] setTitle: str];
>> Current language: auto; currently objective-c
>> (gdb) p name
>> $1 = 4802696161
>> (gdb) xstring
>> $2 = (struct Lisp_String *) 0x11e4353e0
>> "edit of \362\351\370\343 \351\345\342\341's note re: \371\345\354\347
>> \343\345\340\370 \340\354\367\350\370\345\360\351: IMG_0373, IMG_0436,
>> IMG_0456, IMG_0545, IMG_0575, IMG_0596, IMG_0636, IMG_0641, IMG_0744,
>> IMG_0745, IMG_0906, IMG_0925, IMG_1025, IMG_1038, IMG_1121"
>>
>>
>
> That is no utf-8 string (looks like a unibyte string), so the fact that str is
> nil is expected. Is this a filename? In that case there is a bug here,
> filename coding isn't used.
>
> Can you in a shell do:
> % env | grep LANG
> and
> % env | grep LC_
>
> Thanks,
>
> Jan D.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 31 Dec 2010 11:20:03 GMT)
Full text and
rfc822 format available.
Message #62 received at 7517 <at> debbugs.gnu.org (full text, mbox):
it's not a file name. typically when editing a message in vm, the
frame title sais
edit of <sender> re: <subject>
On Fri, Dec 31, 2010 at 1:23 PM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:
> On further thought, it isn't a filename, that would start with / (assuming
> buffer filenames are always absolute). In that case, the question is how a
> buffer name can be a unibyte string?
>
> Jan D.
>
>
> Jan Djärv skrev 2010-12-31 11.49:
>>
>>
>> emacs user skrev 2010-12-31 07.12:
>>>
>>> I forgot to include the first part of this:
>>>
>>> (gdb) fr 10
>>> #10 0x000000010019fd3c in ns_set_name_as_filename (f=0x100b418e0) at
>>> nsfns.m:655
>>> 655 [[view window] setTitle: str];
>>> Current language: auto; currently objective-c
>>> (gdb) p name
>>> $1 = 4802696161
>>> (gdb) xstring
>>> $2 = (struct Lisp_String *) 0x11e4353e0
>>> "edit of \362\351\370\343 \351\345\342\341's note re: \371\345\354\347
>>> \343\345\340\370 \340\354\367\350\370\345\360\351: IMG_0373, IMG_0436,
>>> IMG_0456, IMG_0545, IMG_0575, IMG_0596, IMG_0636, IMG_0641, IMG_0744,
>>> IMG_0745, IMG_0906, IMG_0925, IMG_1025, IMG_1038, IMG_1121"
>>>
>>>
>>
>> That is no utf-8 string (looks like a unibyte string), so the fact that
>> str is
>> nil is expected. Is this a filename? In that case there is a bug here,
>> filename coding isn't used.
>>
>> Can you in a shell do:
>> % env | grep LANG
>> and
>> % env | grep LC_
>>
>> Thanks,
>>
>> Jan D.
>
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 31 Dec 2010 12:44:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 7517 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 31 Dec 2010 11:49:57 +0100
> From: Jan Djärv <jan.h.d <at> swipnet.se>
> Cc: 7517 <at> debbugs.gnu.org, emacs-devel <at> gnu.org,
> Chong Yidong <cyd <at> stupidchicken.com>
>
> > $2 = (struct Lisp_String *) 0x11e4353e0
> > "edit of \362\351\370\343 \351\345\342\341's note re: \371\345\354\347
> > \343\345\340\370 \340\354\367\350\370\345\360\351: IMG_0373, IMG_0436,
> > IMG_0456, IMG_0545, IMG_0575, IMG_0596, IMG_0636, IMG_0641, IMG_0744,
> > IMG_0745, IMG_0906, IMG_0925, IMG_1025, IMG_1038, IMG_1121"
> >
> >
>
> That is no utf-8 string (looks like a unibyte string)
Yes, it's a unibyte string encoded in hebrew-iso-8bit.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 31 Dec 2010 12:45:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 7517 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 31 Dec 2010 12:23:54 +0100
> From: Jan Djärv <jan.h.d <at> swipnet.se>
> Cc: 7517 <at> debbugs.gnu.org, Chong Yidong <cyd <at> stupidchicken.com>,
> Stefan Monnier <monnier <at> iro.umontreal.ca>, emacs-devel <at> gnu.org
>
> On further thought, it isn't a filename, that would start with / (assuming
> buffer filenames are always absolute). In that case, the question is how a
> buffer name can be a unibyte string?
Some bad interaction between VM and Emacs?
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 31 Dec 2010 13:00:04 GMT)
Full text and
rfc822 format available.
Message #71 received at 7517 <at> debbugs.gnu.org (full text, mbox):
On Fri, Dec 31, 2010 at 2:53 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Fri, 31 Dec 2010 12:23:54 +0100
>> From: Jan Djärv <jan.h.d <at> swipnet.se>
>> Cc: 7517 <at> debbugs.gnu.org, Chong Yidong <cyd <at> stupidchicken.com>,
>> Stefan Monnier <monnier <at> iro.umontreal.ca>, emacs-devel <at> gnu.org
>>
>> On further thought, it isn't a filename, that would start with / (assuming
>> buffer filenames are always absolute). In that case, the question is how a
>> buffer name can be a unibyte string?
>
> Some bad interaction between VM and Emacs?
>
yes, and I was hoping to be able to send a bug report about this,
hence the effort to edit the message. but then I ran into this crash
problem. if it could be fixed, I'll try again. it seems, though,
that the crash problem indicates some unnecessary vulnerability of
emacs itself. did you see the original hebrew characters in my
previous message? does this help?
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 31 Dec 2010 13:04:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 7517 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii skrev 2010-12-31 13.53:
>> Date: Fri, 31 Dec 2010 12:23:54 +0100
>> From: Jan Djärv<jan.h.d <at> swipnet.se>
>> Cc: 7517 <at> debbugs.gnu.org, Chong Yidong<cyd <at> stupidchicken.com>,
>> Stefan Monnier<monnier <at> iro.umontreal.ca>, emacs-devel <at> gnu.org
>>
>> On further thought, it isn't a filename, that would start with / (assuming
>> buffer filenames are always absolute). In that case, the question is how a
>> buffer name can be a unibyte string?
>
> Some bad interaction between VM and Emacs?
That may be, but I was under the impression that Emacs internally should use
unicode, so why is it even allowed to set such a buffer name? Shouldn't Emacs
internals complain when given such strings, or convert them (if charset info
is available)?
This will break for X also, as the title setting code assumes ENCODE_UTF_8
will do the trick, and then sets an UTF8_STRING as title. There has been some
VM-related bugs reported for Gtk+ also. This may be the source of a memory
corruption.
Is setting buffer name with a non-ascii unibyte string considered as a bug?
Then this is a VM bug, but perhaps the title setting code should detect this also.
Jan D.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 31 Dec 2010 13:08:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 7517 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 31 Dec 2010 14:52:36 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: cyd <at> stupidchicken.com, 7517 <at> debbugs.gnu.org, user.emacs <at> gmail.com,
> emacs-devel <at> gnu.org
>
> Yes, it's a unibyte string encoded in hebrew-iso-8bit.
^^^^^^^^^^^^^^^
AKA 8869-8.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 31 Dec 2010 13:10:04 GMT)
Full text and
rfc822 format available.
Message #80 received at 7517 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 31 Dec 2010 14:10:45 +0100
> From: Jan Djärv <jan.h.d <at> swipnet.se>
> CC: user.emacs <at> gmail.com, 7517 <at> debbugs.gnu.org, cyd <at> stupidchicken.com,
> monnier <at> iro.umontreal.ca, emacs-devel <at> gnu.org
>
> > Some bad interaction between VM and Emacs?
>
> That may be, but I was under the impression that Emacs internally should use
> unicode, so why is it even allowed to set such a buffer name? Shouldn't Emacs
> internals complain when given such strings, or convert them (if charset info
> is available)?
Probably, but more information is needed. Did you already find the
place where this string is used to create a buffer? If so, can you
show me that place, and explain what sequence of calls led to it?
> Is setting buffer name with a non-ascii unibyte string considered as a bug?
Yes, I think so. Emacs should never use unibyte strings for buffer
names.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 31 Dec 2010 13:12:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 7517 <at> debbugs.gnu.org (full text, mbox):
I hope I fixed the crash, but the title will be wrong. Try the latest version
from trunk.
Jan D.
emacs user skrev 2010-12-31 14.06:
> On Fri, Dec 31, 2010 at 2:53 PM, Eli Zaretskii<eliz <at> gnu.org> wrote:
>>> Date: Fri, 31 Dec 2010 12:23:54 +0100
>>> From: Jan Djärv<jan.h.d <at> swipnet.se>
>>> Cc: 7517 <at> debbugs.gnu.org, Chong Yidong<cyd <at> stupidchicken.com>,
>>> Stefan Monnier<monnier <at> iro.umontreal.ca>, emacs-devel <at> gnu.org
>>>
>>> On further thought, it isn't a filename, that would start with / (assuming
>>> buffer filenames are always absolute). In that case, the question is how a
>>> buffer name can be a unibyte string?
>>
>> Some bad interaction between VM and Emacs?
>>
>
> yes, and I was hoping to be able to send a bug report about this,
> hence the effort to edit the message. but then I ran into this crash
> problem. if it could be fixed, I'll try again. it seems, though,
> that the crash problem indicates some unnecessary vulnerability of
> emacs itself. did you see the original hebrew characters in my
> previous message? does this help?
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 31 Dec 2010 14:17:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 7517 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii skrev 2010-12-31 14.19:
>> Date: Fri, 31 Dec 2010 14:10:45 +0100
>> From: Jan Djärv<jan.h.d <at> swipnet.se>
>> CC: user.emacs <at> gmail.com, 7517 <at> debbugs.gnu.org, cyd <at> stupidchicken.com,
>> monnier <at> iro.umontreal.ca, emacs-devel <at> gnu.org
>>
>>> Some bad interaction between VM and Emacs?
>>
>> That may be, but I was under the impression that Emacs internally should use
>> unicode, so why is it even allowed to set such a buffer name? Shouldn't Emacs
>> internals complain when given such strings, or convert them (if charset info
>> is available)?
>
> Probably, but more information is needed. Did you already find the
> place where this string is used to create a buffer? If so, can you
> show me that place, and explain what sequence of calls led to it?
>
The OP have to confirm, but it is in
(defun vm-edit-message (&optional prefix-argument)
"Edit the current message. Prefix arg means mark as unedited instead.
If editing, the current message is copied into a temporary buffer, and
this buffer is selected for editing. The major mode of this buffer is
controlled by the variable vm-edit-message-mode. The hooks specified
in vm-edit-message-hook are run just prior to returning control to the user
for editing.
Use C-c ESC when you have finished editing the message. The message
will be inserted into its folder replacing the old version of the
message. If you don't want your edited version of the message to
replace the original, use C-c C-] and the edit will be aborted."
...
(if (not (and edit-buf (buffer-name edit-buf)))
(progn
(vm-save-restriction
(widen)
(setq edit-buf
(generate-new-buffer
(format "edit of %s's note re: %s"
(vm-su-full-name (car vm-message-pointer))
(vm-su-subject (car vm-message-pointer)))))
Jan D.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 31 Dec 2010 15:59:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 7517 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 31 Dec 2010 15:22:56 +0100
> From: Jan Djärv <jan.h.d <at> swipnet.se>
> CC: user.emacs <at> gmail.com, 7517 <at> debbugs.gnu.org, cyd <at> stupidchicken.com,
> monnier <at> iro.umontreal.ca, emacs-devel <at> gnu.org
>
> (generate-new-buffer
> (format "edit of %s's note re: %s"
> (vm-su-full-name (car vm-message-pointer))
> (vm-su-subject (car vm-message-pointer)))))
So I guess VM holds the message in its undecoded (external) format?
If so, it should do this:
(format "edit of %s's note re: %s"
(decode-coding-string
(vm-su-full-name (car vm-message-pointer))
SOMETHING)
(decode-coding-string
(vm-su-subject (car vm-message-pointer))
SOMETHING))
Quite what to use for SOMETHING depends on whether VM knows the
encoding of the message. If it does, it should use that; otherwise
using `undecided' should DTRT in most cases.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 31 Dec 2010 16:03:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 7517 <at> debbugs.gnu.org (full text, mbox):
I am copying Uday in case he is interested in all this... E
On Fri, Dec 31, 2010 at 6:07 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Fri, 31 Dec 2010 15:22:56 +0100
>> From: Jan Djärv <jan.h.d <at> swipnet.se>
>> CC: user.emacs <at> gmail.com, 7517 <at> debbugs.gnu.org, cyd <at> stupidchicken.com,
>> monnier <at> iro.umontreal.ca, emacs-devel <at> gnu.org
>>
>> (generate-new-buffer
>> (format "edit of %s's note re: %s"
>> (vm-su-full-name (car vm-message-pointer))
>> (vm-su-subject (car vm-message-pointer)))))
>
> So I guess VM holds the message in its undecoded (external) format?
> If so, it should do this:
>
> (format "edit of %s's note re: %s"
> (decode-coding-string
> (vm-su-full-name (car vm-message-pointer))
> SOMETHING)
> (decode-coding-string
> (vm-su-subject (car vm-message-pointer))
> SOMETHING))
>
> Quite what to use for SOMETHING depends on whether VM knows the
> encoding of the message. If it does, it should use that; otherwise
> using `undecided' should DTRT in most cases.
>
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 31 Dec 2010 16:50:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 7517 <at> debbugs.gnu.org (full text, mbox):
> Emacs should never use unibyte strings for buffer names.
I don't think we make any effort to prevent this from happening.
And I'm not completely sure that it would be worth the trouble either:
I suspect that wherever a unibyte buffer-name would cause problem
(mode-line, window title, younameit), some other unibyte string could
appear from elsewhere just as well, so enforcing multibyte buffer-names
wouldn't close the vulnerabilities.
Stefan
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 31 Dec 2010 17:36:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 7517 <at> debbugs.gnu.org (full text, mbox):
anyway, the fix worked and crashes are gone! frame title is now "bad
coding". many thanks for this. E
On Fri, Dec 31, 2010 at 6:56 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>> Emacs should never use unibyte strings for buffer names.
>
> I don't think we make any effort to prevent this from happening.
>
> And I'm not completely sure that it would be worth the trouble either:
> I suspect that wherever a unibyte buffer-name would cause problem
> (mode-line, window title, younameit), some other unibyte string could
> appear from elsewhere just as well, so enforcing multibyte buffer-names
> wouldn't close the vulnerabilities.
>
>
> Stefan
>
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 31 Dec 2010 18:51:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 7517 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii skrev 2010-12-31 17.07:
>> Date: Fri, 31 Dec 2010 15:22:56 +0100
>> From: Jan Djärv<jan.h.d <at> swipnet.se>
>> CC: user.emacs <at> gmail.com, 7517 <at> debbugs.gnu.org, cyd <at> stupidchicken.com,
>> monnier <at> iro.umontreal.ca, emacs-devel <at> gnu.org
>>
>> (generate-new-buffer
>> (format "edit of %s's note re: %s"
>> (vm-su-full-name (car vm-message-pointer))
>> (vm-su-subject (car vm-message-pointer)))))
>
> So I guess VM holds the message in its undecoded (external) format?
> If so, it should do this:
>
> (format "edit of %s's note re: %s"
> (decode-coding-string
> (vm-su-full-name (car vm-message-pointer))
> SOMETHING)
> (decode-coding-string
> (vm-su-subject (car vm-message-pointer))
> SOMETHING))
>
> Quite what to use for SOMETHING depends on whether VM knows the
> encoding of the message. If it does, it should use that; otherwise
> using `undecided' should DTRT in most cases.
>
But not in this case. The given string is not decoded right with undecided.
detect-coding-string doesn't list iso-8859-8. I think choosing between
iso-8859-x is difficult. Still, VM should know the coding used.
Jan D.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 31 Dec 2010 22:24:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 7517 <at> debbugs.gnu.org (full text, mbox):
On Fri, Dec 31, 2010 at 6:56 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>> Emacs should never use unibyte strings for buffer names.
>
> I don't think we make any effort to prevent this from happening.
>
> And I'm not completely sure that it would be worth the trouble either:
> I suspect that wherever a unibyte buffer-name would cause problem
> (mode-line, window title, younameit), some other unibyte string could
> appear from elsewhere just as well, so enforcing multibyte buffer-names
> wouldn't close the vulnerabilities.
If we don't at least ENCODE_UTF_8 should do the right thing. Is the coding
for these kind of strings known? If not and we don't enforce encoding in
basic interfaces, we must deal with all existing encodings?
Jan D.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Fri, 31 Dec 2010 23:01:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 7517 <at> debbugs.gnu.org (full text, mbox):
>>> Emacs should never use unibyte strings for buffer names.
>> I don't think we make any effort to prevent this from happening.
>> And I'm not completely sure that it would be worth the trouble either:
>> I suspect that wherever a unibyte buffer-name would cause problem
>> (mode-line, window title, younameit), some other unibyte string could
>> appear from elsewhere just as well, so enforcing multibyte buffer-names
>> wouldn't close the vulnerabilities.
> If we don't at least ENCODE_UTF_8 should do the right thing. Is the coding
> for these kind of strings known? If not and we don't enforce encoding in
> basic interfaces, we must deal with all existing encodings?
I'd tend to agree. ENCODE_UTF_8 is used for things where we *really*
want the output to be proper utf-8, so any char outside of utf-8
(e.g. an eight-bit char) should result in something else than a raw byte
in the output. This is contrary to what we do for utf-8 files, where we
output eight-bit chars as raw bytes (because any sequence of bytes
that's not valid utf-8 in the input leads to such eight-bit chars in
the buffer, so outputting them as raw bytes is used to preserve the
file unchanged when saved).
Stefan
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Sat, 01 Jan 2011 04:43:03 GMT)
Full text and
rfc822 format available.
Message #110 received at 7517 <at> debbugs.gnu.org (full text, mbox):
Jan Djärv writes:
> But not in this case. The given string is not decoded right with undecided.
> detect-coding-string doesn't list iso-8859-8. I think choosing between
> iso-8859-x is difficult. Still, VM should know the coding used.
It does for standards conforming mail. But VM can't do anything when
people put literal 8-bit codes in the headers without MIME encoding,
which still happens occasionally in legit mail (and is very frequent
in abusive mail), or in the body without a Content-Type charset
parameter. It has to leave that up to Emacs, or recode to UNKNOWN
(aka application/octet-stream).
VM used to quite ornery about such stuff, and simply refuse to deal
with it. It's gotten lax in its old age, I guess.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Sat, 01 Jan 2011 11:49:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 7517 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: emacs user <user.emacs <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>, 7517 <at> debbugs.gnu.org, cyd <at> stupidchicken.com, emacs-devel <at> gnu.org, "Uday S. Reddy" <u.s.reddy <at> cs.bham.ac.uk>
> Date: Fri, 31 Dec 2010 18:07:22 -0500
>
> I'd tend to agree. ENCODE_UTF_8 is used for things where we *really*
> want the output to be proper utf-8, so any char outside of utf-8
> (e.g. an eight-bit char) should result in something else than a raw byte
> in the output.
The only thing it can do is output the replacement character U+FFFD,
or `?', or characters in the range U+DC80..U+DCFF. I tend to think
that `?' is the best alternative.
> This is contrary to what we do for utf-8 files
So we should have a different encoding symbol for these two variants.
I still maintain that VM should do better in this case. I don't think
we have a clear idea of what happened in this particular crash, so
perhaps is too soon to forget about VM's part.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Sat, 01 Jan 2011 11:52:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 7517 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 31 Dec 2010 23:30:31 +0100
> From: Jan Djärv <jan.h.d <at> swipnet.se>
> CC: Stefan Monnier <monnier <at> iro.umontreal.ca>,
> Eli Zaretskii <eliz <at> gnu.org>,
> 7517 <at> debbugs.gnu.org, cyd <at> stupidchicken.com, emacs-devel <at> gnu.org,
> "Uday S. Reddy" <u.s.reddy <at> cs.bham.ac.uk>
>
> Is the coding for these kind of strings known?
It might be: the string could have a `charset' text property on it.
Other than that, I think VM should try to decide the encoding from the
context, such as the encoding of the message body. (Of course, I'm
talking out of sheer ignorance about VM, so apologies if this happens
to be hogwash.)
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Sat, 01 Jan 2011 12:40:03 GMT)
Full text and
rfc822 format available.
Message #119 received at 7517 <at> debbugs.gnu.org (full text, mbox):
On Sat, Jan 1, 2011 at 1:57 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> I still maintain that VM should do better in this case. I don't think
> we have a clear idea of what happened in this particular crash, so
> perhaps is too soon to forget about VM's part.
here is a bug report I just sent the vm maintainers now that I could
edit the message thanks to your help.
Subject: =?iso-8859-8-i?B?+eXs5yDj5eD4IODs9+j45fDpOiBJTUdfMTYxNiwgSU1HXzE2MTgsIElN?=
=?iso-8859-8-i?B?R18xNjIw?=
is displayed as
Subject: \371\345\354\347 \343\345\340\370
\340\354\367\350\370\345\360\351: IMG_1616, IMG_1618, IMG_1620
instead of
Subject: שולח דואר אלקטרוני: IMG_1616, IMG_1618, IMG_1620
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Sat, 01 Jan 2011 15:33:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 7517 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 1 Jan 2011 14:46:24 +0200
> From: emacs user <user.emacs <at> gmail.com>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, jan.h.d <at> swipnet.se, 7517 <at> debbugs.gnu.org,
> cyd <at> stupidchicken.com, emacs-devel <at> gnu.org, u.s.reddy <at> cs.bham.ac.uk
>
> On Sat, Jan 1, 2011 at 1:57 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> here is a bug report I just sent the vm maintainers now that I could
> edit the message thanks to your help.
>
> Subject: =?iso-8859-8-i?B?+eXs5yDj5eD4IODs9+j45fDpOiBJTUdfMTYxNiwgSU1HXzE2MTgsIElN?=
> =?iso-8859-8-i?B?R18xNjIw?=
>
> is displayed as
>
> Subject: \371\345\354\347 \343\345\340\370
> \340\354\367\350\370\345\360\351: IMG_1616, IMG_1618, IMG_1620
>
> instead of
>
> Subject: שולח דואר אלקטרוני: IMG_1616, IMG_1618, IMG_1620
Thanks. It sounds like VM doesn't know about ISO-8859-8-i, is that
right?
I guess this bug report can be closed now. Any objections?
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Sat, 01 Jan 2011 16:56:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 7517 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii writes:
> Thanks. It sounds like VM doesn't know about ISO-8859-8-i, is that
> right?
I have just begun to look at this. VM isn't doing it carefully at the
moment. The problem of migrating from an English-only context to
international character sets.
> I guess this bug report can be closed now. Any objections?
I think so. Thanks for all the tips.
Happy 2011 to all!
Uday
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Sat, 01 Jan 2011 17:05:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 7517 <at> debbugs.gnu.org (full text, mbox):
> Other than that, I think VM should try to decide the encoding from the
> context, such as the encoding of the message body.
It can also keep the text as raw 8bit bytes, since such unlabeled
non-ascii chars in a email header as invalid anyway. It's up to the VM
maintainer to decide what's best for its users. We just have to make
sure we don't crash even if we get weird chars.
Stefan
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Sat, 01 Jan 2011 17:16:01 GMT)
Full text and
rfc822 format available.
Message #131 received at 7517 <at> debbugs.gnu.org (full text, mbox):
> The only thing it can do is output the replacement character U+FFFD,
> or `?', or characters in the range U+DC80..U+DCFF. I tend to think
> that `?' is the best alternative.
Any output is fine by me. We could try and output a chunk of text like
U+NNNN, but a simple ? would do as well.
>> This is contrary to what we do for utf-8 files
> So we should have a different encoding symbol for these two variants.
Indeed. Maybe we could call the new one `valid-utf-8'.
> I still maintain that VM should do better in this case. I don't think
> we have a clear idea of what happened in this particular crash, so
> perhaps is too soon to forget about VM's part.
No matter what VM does Emacs shouldn't crash.
Stefan
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Sat, 01 Jan 2011 17:58:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 7517 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Jan Djärv <jan.h.d <at> swipnet.se>,
> user.emacs <at> gmail.com, 7517 <at> debbugs.gnu.org, cyd <at> stupidchicken.com,
> emacs-devel <at> gnu.org, u.s.reddy <at> cs.bham.ac.uk
> Date: Sat, 01 Jan 2011 12:11:26 -0500
>
> > Other than that, I think VM should try to decide the encoding from the
> > context, such as the encoding of the message body.
>
> It can also keep the text as raw 8bit bytes, since such unlabeled
> non-ascii chars in a email header as invalid anyway.
As we see from the OP's last message, the email header was actually
RFC2047-correct.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Sat, 01 Jan 2011 17:59:01 GMT)
Full text and
rfc822 format available.
Message #137 received at 7517 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: jan.h.d <at> swipnet.se, user.emacs <at> gmail.com, 7517 <at> debbugs.gnu.org, cyd <at> stupidchicken.com, emacs-devel <at> gnu.org, u.s.reddy <at> cs.bham.ac.uk
> Date: Sat, 01 Jan 2011 12:22:30 -0500
>
> > I still maintain that VM should do better in this case. I don't think
> > we have a clear idea of what happened in this particular crash, so
> > perhaps is too soon to forget about VM's part.
>
> No matter what VM does Emacs shouldn't crash.
Of course; but I think Jan already fixed that.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Sat, 01 Jan 2011 18:00:04 GMT)
Full text and
rfc822 format available.
Notification sent
to
emacs user <user.emacs <at> gmail.com>:
bug acknowledged by developer.
(Sat, 01 Jan 2011 18:00:04 GMT)
Full text and
rfc822 format available.
Message #142 received at 7517-done <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 1 Jan 2011 17:02:37 +0000
> From: Uday S Reddy <u.s.reddy <at> cs.bham.ac.uk>
> Cc: 7517 <at> debbugs.gnu.org,
> emacs-devel <at> gnu.org,
> u.s.reddy <at> cs.bham.ac.uk
>
> Eli Zaretskii writes:
>
> > Thanks. It sounds like VM doesn't know about ISO-8859-8-i, is that
> > right?
>
> I have just begun to look at this. VM isn't doing it carefully at the
> moment. The problem of migrating from an English-only context to
> international character sets.
>
> > I guess this bug report can be closed now. Any objections?
>
> I think so.
Done.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Sat, 01 Jan 2011 18:28:02 GMT)
Full text and
rfc822 format available.
Message #145 received at 7517 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii skrev 2011-01-01 16:40:
> right?
>
> I guess this bug report can be closed now. Any objections?
No.
Jan D.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Sun, 02 Jan 2011 13:56:01 GMT)
Full text and
rfc822 format available.
Message #148 received at 7517 <at> debbugs.gnu.org (full text, mbox):
"Jan D." <jan.h.d <at> swipnet.se> writes:
> Eli Zaretskii skrev 2011-01-01 16:40:
>
>> right?
>>
>> I guess this bug report can be closed now. Any objections?
>
> No.
Please backport the fix to the emacs-23 branch, thanks.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7517; Package
emacs,ns.
(Mon, 03 Jan 2011 21:27:01 GMT)
Full text and
rfc822 format available.
Message #151 received at 7517 <at> debbugs.gnu.org (full text, mbox):
Done.
Jan D.
Chong Yidong skrev 2011-01-02 15.02:
> "Jan D."<jan.h.d <at> swipnet.se> writes:
>
>> Eli Zaretskii skrev 2011-01-01 16:40:
>>
>>> right?
>>>
>>> I guess this bug report can be closed now. Any objections?
>>
>> No.
>
> Please backport the fix to the emacs-23 branch, thanks.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 01 Feb 2011 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 14 years and 142 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.