* bug#7517: 24.0.50; repeated crash under Mac OS X
@ 2010-11-29 14:22 emacs user
2010-12-17 11:47 ` Chong Yidong
0 siblings, 1 reply; 49+ messages in thread
From: emacs user @ 2010-11-29 14:22 UTC (permalink / raw)
To: 7517
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)
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
2010-11-29 14:22 bug#7517: 24.0.50; repeated crash under Mac OS X emacs user
@ 2010-12-17 11:47 ` Chong Yidong
2010-12-17 23:07 ` emacs user
` (2 more replies)
0 siblings, 3 replies; 49+ messages in thread
From: Chong Yidong @ 2010-12-17 11:47 UTC (permalink / raw)
To: emacs user; +Cc: 7517
emacs user <user.emacs@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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
2010-12-17 11:47 ` Chong Yidong
@ 2010-12-17 23:07 ` emacs user
2010-12-17 23:42 ` emacs user
[not found] ` <AANLkTinQHfFXazEbf+qxtz5+MfKcaXQLN18nPnyQMj8X@mail.gmail.com>
2 siblings, 0 replies; 49+ messages in thread
From: emacs user @ 2010-12-17 23:07 UTC (permalink / raw)
To: Chong Yidong; +Cc: 7517
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.
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
2010-12-17 11:47 ` Chong Yidong
2010-12-17 23:07 ` emacs user
@ 2010-12-17 23:42 ` emacs user
[not found] ` <AANLkTinQHfFXazEbf+qxtz5+MfKcaXQLN18nPnyQMj8X@mail.gmail.com>
2 siblings, 0 replies; 49+ messages in thread
From: emacs user @ 2010-12-17 23:42 UTC (permalink / raw)
To: Chong Yidong; +Cc: 7517
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@stupidchicken.com> wrote:
> emacs user <user.emacs@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.
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <AANLkTinQHfFXazEbf+qxtz5+MfKcaXQLN18nPnyQMj8X@mail.gmail.com>
@ 2010-12-26 18:43 ` emacs user
2010-12-29 4:29 ` Chong Yidong
[not found] ` <87vd2dyzfj.fsf@stupidchicken.com>
0 siblings, 2 replies; 49+ messages in thread
From: emacs user @ 2010-12-26 18:43 UTC (permalink / raw)
To: Chong Yidong, 7517
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@stupidchicken.com> wrote:
>> emacs user <user.emacs@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.
>>
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
2010-12-26 18:43 ` emacs user
@ 2010-12-29 4:29 ` Chong Yidong
[not found] ` <87vd2dyzfj.fsf@stupidchicken.com>
1 sibling, 0 replies; 49+ messages in thread
From: Chong Yidong @ 2010-12-29 4:29 UTC (permalink / raw)
To: emacs-devel; +Cc: 7517, emacs user
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@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?
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <87vd2dyzfj.fsf@stupidchicken.com>
@ 2010-12-29 11:59 ` Jan Djärv
[not found] ` <4D1B22A1.6080202@swipnet.se>
1 sibling, 0 replies; 49+ messages in thread
From: Jan Djärv @ 2010-12-29 11:59 UTC (permalink / raw)
To: Chong Yidong; +Cc: 7517, emacs user, emacs-devel
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@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?
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <4D1B22A1.6080202@swipnet.se>
@ 2010-12-29 12:21 ` Jan Djärv
[not found] ` <4D1B27AF.7010701@swipnet.se>
1 sibling, 0 replies; 49+ messages in thread
From: Jan Djärv @ 2010-12-29 12:21 UTC (permalink / raw)
To: Chong Yidong; +Cc: 7517, emacs user, emacs-devel
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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <4D1B27AF.7010701@swipnet.se>
@ 2010-12-29 15:41 ` Stefan Monnier
[not found] ` <jwvpqskio2r.fsf-monnier+emacs@gnu.org>
1 sibling, 0 replies; 49+ messages in thread
From: Stefan Monnier @ 2010-12-29 15:41 UTC (permalink / raw)
To: Jan Djärv; +Cc: Chong Yidong, 7517, emacs user, emacs-devel
> 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
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <jwvpqskio2r.fsf-monnier+emacs@gnu.org>
@ 2010-12-29 16:06 ` emacs user
2010-12-30 11:35 ` Jan Djärv
[not found] ` <4D1C6E7D.2040300@swipnet.se>
0 siblings, 2 replies; 49+ messages in thread
From: emacs user @ 2010-12-29 16:06 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Chong Yidong, 7517, emacs-devel
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@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
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
2010-12-29 16:06 ` emacs user
@ 2010-12-30 11:35 ` Jan Djärv
[not found] ` <4D1C6E7D.2040300@swipnet.se>
1 sibling, 0 replies; 49+ messages in thread
From: Jan Djärv @ 2010-12-30 11:35 UTC (permalink / raw)
To: emacs user; +Cc: 7517, emacs-devel, Chong Yidong
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@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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <4D1C6E7D.2040300@swipnet.se>
@ 2010-12-30 14:20 ` emacs user
2010-12-30 22:02 ` Jan Djärv
[not found] ` <4D1D0172.8080404@swipnet.se>
0 siblings, 2 replies; 49+ messages in thread
From: emacs user @ 2010-12-30 14:20 UTC (permalink / raw)
To: Jan Djärv; +Cc: 7517, emacs-devel, Chong Yidong
[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]
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@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@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.
>
[-- Attachment #2: t --]
[-- Type: application/octet-stream, Size: 18958 bytes --]
udp003246uds:/usr/local/emacs/trunk/src $ gdb /usr/local/emacs/trunk/nextstep/Emacs.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
DISPLAY = /tmp/launch-3xISIt/org.x:0
TERM = xterm
Breakpoint 1 at 0x4189374bb95c7f
Breakpoint 2 at 0x1000ce3b2: file sysdep.c, line 836.
(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
2010-12-30 09:16:45.500 Emacs[65787:a0f] *** Assertion failure in -[EmacsWindow setTitle:], /SourceCache/AppKit/AppKit-1038.35/AppKit.subproj/NSWindow.m:2036
2010-12-30 09:16:45.505 Emacs[65787:a0f] An uncaught exception was raised
2010-12-30 09:16:45.505 Emacs[65787:a0f] Invalid parameter not satisfying: aString != nil
2010-12-30 09:16:45.508 Emacs[65787: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 0x000000010019fd3c ns_set_name_as_filename + 860
6 Emacs 0x0000000100030bd5 prepare_menu_bars + 741
7 Emacs 0x00000001000371ea redisplay_internal + 3258
8 Emacs 0x00000001000bf818 read_char + 2312
9 Emacs 0x00000001000c200c read_key_sequence + 1340
10 Emacs 0x00000001000c45c2 command_loop_1 + 610
11 Emacs 0x0000000100129355 internal_condition_case + 325
12 Emacs 0x00000001000b9b57 command_loop_2 + 55
13 Emacs 0x0000000100129451 internal_catch + 225
14 Emacs 0x00000001000b9da6 command_loop + 182
15 Emacs 0x00000001000ba21f recursive_edit_1 + 159
16 Emacs 0x00000001000ba3bf Frecursive_edit + 287
17 Emacs 0x00000001000b20d8 main + 3192
18 Emacs 0x0000000100001894 start + 52
)
terminate called after throwing an instance of 'NSException'
Breakpoint 1, 0x00007fff840a3c7f in abort ()
(gdb) where
#0 0x00007fff840a3c7f in abort ()
#1 0x00007fff888e15d2 in __gnu_cxx::__verbose_terminate_handler ()
#2 0x00007fff83f0ad29 in _objc_terminate ()
#3 0x00007fff888dfae1 in __cxxabiv1::__terminate ()
#4 0x00007fff888dfb16 in std::terminate ()
#5 0x00007fff888dfbfc in __cxa_throw ()
#6 0x00007fff83f07192 in objc_exception_throw ()
#7 0x00007fff842275d7 in +[NSException raise:format:arguments:] ()
#8 0x00007fff8394687a in -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] ()
#9 0x00007fff8052ab98 in -[NSWindow setTitle:] ()
#10 0x000000010019fd3c in ns_set_name_as_filename (f=0x100f3dcb0) at nsfns.m:655
#11 0x0000000100030bd5 in prepare_menu_bars () at xdisp.c:9843
#12 0x00000001000371ea in redisplay_internal (preserve_echo_area=<value temporarily unavailable, due to optimizations>) at xdisp.c:11757
#13 0x00000001000bf818 in read_char (commandflag=1, nmaps=3, maps=0x7fff5fbfdf60, prev_event=4328534074, used_mouse_menu=0x7fff5fbfe194, end_time=0x0) at keyboard.c:2560
#14 0x00000001000c200c in read_key_sequence (keybuf=0x7fff5fbfe230, bufsize=30, prompt=4328534074, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9406
#15 0x00000001000c45c2 in command_loop_1 () at keyboard.c:1607
#16 0x0000000100129355 in internal_condition_case (bfun=0x1000c4360 <command_loop_1>, handlers=4328590138, hfun=0x1000b9fa0 <cmd_error>) at eval.c:1462
#17 0x00000001000b9b57 in command_loop_2 (ignore=<value temporarily unavailable, due to optimizations>) at keyboard.c:1327
#18 0x0000000100129451 in internal_catch (tag=<value temporarily unavailable, due to optimizations>, func=0x1000b9b20 <command_loop_2>, arg=4328534074) at eval.c:1206
#19 0x00000001000b9da6 in command_loop () at keyboard.c:1306
#20 0x00000001000ba21f in recursive_edit_1 () at keyboard.c:929
#21 0x00000001000ba3bf in Frecursive_edit () at keyboard.c:991
#22 0x00000001000b20d8 in main (argc=1, argv=0x7fff5fbfe818) at emacs.c:1716
(gdb) xbacktrace full
(gdb) bt full
#0 0x00007fff840a3c7f in abort ()
No symbol table info available.
#1 0x00007fff888e15d2 in __gnu_cxx::__verbose_terminate_handler ()
No symbol table info available.
#2 0x00007fff83f0ad29 in _objc_terminate ()
No symbol table info available.
#3 0x00007fff888dfae1 in __cxxabiv1::__terminate ()
No symbol table info available.
#4 0x00007fff888dfb16 in std::terminate ()
No symbol table info available.
#5 0x00007fff888dfbfc in __cxa_throw ()
No symbol table info available.
#6 0x00007fff83f07192 in objc_exception_throw ()
No symbol table info available.
#7 0x00007fff842275d7 in +[NSException raise:format:arguments:] ()
No symbol table info available.
#8 0x00007fff8394687a in -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] ()
No symbol table info available.
#9 0x00007fff8052ab98 in -[NSWindow setTitle:] ()
No symbol table info available.
#10 0x000000010019fd3c in ns_set_name_as_filename (f=0x100f3dcb0) at nsfns.m:655
str = (NSString *) 0x0
view = (NSView *) 0x100fe25b0
name = 4825128705
buf = <value temporarily unavailable, due to optimizations>
title = <value temporarily unavailable, due to optimizations>
encoded_name = 4827023921
#11 0x0000000100030bd5 in prepare_menu_bars () at xdisp.c:9843
tail = <value temporarily unavailable, due to optimizations>
fmt = <value temporarily unavailable, due to optimizations>
len = 0
title = 0x100f0bb60 ""
it = {
window = 4804076357,
w = 0x11e586340,
f = 0x100f3dcb0,
method = GET_FROM_BUFFER,
stop_charpos = 0,
prev_stop = 0,
base_level_stop = 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 = 0x116ec28c0,
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_charpos = 0,
overlay_strings = {0 <repeats 16 times>},
string_overlays = {0 <repeats 16 times>},
string = 4328534074,
from_overlay = 0,
stack = {{
string = 0,
string_nchars = 0,
end_charpos = 0,
stop_charpos = 0,
prev_stop = 0,
base_level_stop = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = 0,
charpos = 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,
prev_stop = 0,
base_level_stop = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = 0,
charpos = 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,
prev_stop = 0,
base_level_stop = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = 0,
charpos = 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,
prev_stop = 0,
base_level_stop = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = 0,
charpos = 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,
prev_stop = 0,
base_level_stop = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = 0,
charpos = 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,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = 0,
charpos = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
char_to_display = 0,
glyphless_method = GLYPHLESS_DISPLAY_THIN_SPACE,
image_id = 0,
slice = {
x = 4328534074,
y = 4328534074,
width = 4328534074,
height = 4328534074
},
space_width = 4328534074,
voffset = 0,
tab_width = 8,
font_height = 4328534074,
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 = 1008,
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,
eol_pos = {
charpos = 0,
bytepos = 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,
bidi_p = 0,
bidi_it = {
bytepos = 0,
charpos = 0,
ch = 0,
ch_len = 0,
type = UNKNOWN_BT,
type_after_w1 = UNKNOWN_BT,
orig_type = UNKNOWN_BT,
resolved_level = 0,
invalid_levels = 0,
invalid_rl_levels = 0,
prev_was_pdf = 0,
prev = {
bytepos = 0,
charpos = 0,
type = UNKNOWN_BT,
type_after_w1 = UNKNOWN_BT,
orig_type = UNKNOWN_BT
},
last_strong = {
bytepos = 0,
charpos = 0,
type = UNKNOWN_BT,
type_after_w1 = UNKNOWN_BT,
orig_type = UNKNOWN_BT
},
next_for_neutral = {
bytepos = 0,
charpos = 0,
type = UNKNOWN_BT,
type_after_w1 = UNKNOWN_BT,
orig_type = UNKNOWN_BT
},
prev_for_neutral = {
bytepos = 0,
charpos = 0,
type = UNKNOWN_BT,
type_after_w1 = UNKNOWN_BT,
orig_type = UNKNOWN_BT
},
next_for_ws = {
bytepos = 0,
charpos = 0,
type = UNKNOWN_BT,
type_after_w1 = UNKNOWN_BT,
orig_type = UNKNOWN_BT
},
next_en_pos = 0,
ignore_bn_limit = 0,
sor = NEUTRAL_DIR,
scan_dir = 0,
stack_idx = 0,
level_stack = {{
level = 0,
override = NEUTRAL_DIR
} <repeats 64 times>},
first_elt = 0,
paragraph_dir = NEUTRAL_DIR,
new_paragraph = 0,
separator_limit = 0
},
paragraph_embedding = NEUTRAL_DIR
}
f = <value temporarily unavailable, due to optimizations>
frame = Cannot access memory at address 0x0
(gdb)
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
2010-12-30 14:20 ` emacs user
@ 2010-12-30 22:02 ` Jan Djärv
[not found] ` <4D1D0172.8080404@swipnet.se>
1 sibling, 0 replies; 49+ messages in thread
From: Jan Djärv @ 2010-12-30 22:02 UTC (permalink / raw)
To: emacs user; +Cc: 7517, emacs-devel, Chong Yidong
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@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@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.
>>
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <4D1D0172.8080404@swipnet.se>
@ 2010-12-31 6:11 ` emacs user
2010-12-31 6:12 ` emacs user
1 sibling, 0 replies; 49+ messages in thread
From: emacs user @ 2010-12-31 6:11 UTC (permalink / raw)
To: Jan Djärv; +Cc: 7517, emacs-devel, Chong Yidong
(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@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@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@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.
>>>
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <4D1D0172.8080404@swipnet.se>
2010-12-31 6:11 ` emacs user
@ 2010-12-31 6:12 ` emacs user
2010-12-31 8:18 ` Eli Zaretskii
` (3 more replies)
1 sibling, 4 replies; 49+ messages in thread
From: emacs user @ 2010-12-31 6:12 UTC (permalink / raw)
To: Jan Djärv; +Cc: 7517, emacs-devel, Chong Yidong
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@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@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@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.
>>>
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
2010-12-31 6:12 ` emacs user
@ 2010-12-31 8:18 ` Eli Zaretskii
2010-12-31 10:49 ` Jan Djärv
` (2 subsequent siblings)
3 siblings, 0 replies; 49+ messages in thread
From: Eli Zaretskii @ 2010-12-31 8:18 UTC (permalink / raw)
To: emacs user; +Cc: 7517, cyd, emacs-devel
> Date: Fri, 31 Dec 2010 08:12:23 +0200
> From: emacs user <user.emacs@gmail.com>
> Cc: 7517@debbugs.gnu.org, emacs-devel@gnu.org,
> Chong Yidong <cyd@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?
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
2010-12-31 6:12 ` emacs user
2010-12-31 8:18 ` Eli Zaretskii
@ 2010-12-31 10:49 ` Jan Djärv
[not found] ` <83ipyabbj1.fsf@gnu.org>
[not found] ` <4D1DB555.5080002@swipnet.se>
3 siblings, 0 replies; 49+ messages in thread
From: Jan Djärv @ 2010-12-31 10:49 UTC (permalink / raw)
To: emacs user; +Cc: 7517, emacs-devel, Chong Yidong
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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <83ipyabbj1.fsf@gnu.org>
@ 2010-12-31 11:16 ` emacs user
0 siblings, 0 replies; 49+ messages in thread
From: emacs user @ 2010-12-31 11:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 7517, cyd, emacs-devel
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@gnu.org> wrote:
>> Date: Fri, 31 Dec 2010 08:12:23 +0200
>> From: emacs user <user.emacs@gmail.com>
>> Cc: 7517@debbugs.gnu.org, emacs-devel@gnu.org,
>> Chong Yidong <cyd@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?
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <4D1DB555.5080002@swipnet.se>
@ 2010-12-31 11:23 ` Jan Djärv
[not found] ` <4D1DBD4A.6010303@swipnet.se>
` (2 subsequent siblings)
3 siblings, 0 replies; 49+ messages in thread
From: Jan Djärv @ 2010-12-31 11:23 UTC (permalink / raw)
To: emacs user; +Cc: 7517, emacs-devel, Chong Yidong
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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <4D1DBD4A.6010303@swipnet.se>
@ 2010-12-31 11:26 ` emacs user
2010-12-31 12:53 ` Eli Zaretskii
[not found] ` <83d3oiaysj.fsf@gnu.org>
2 siblings, 0 replies; 49+ messages in thread
From: emacs user @ 2010-12-31 11:26 UTC (permalink / raw)
To: Jan Djärv; +Cc: 7517, emacs-devel, Chong Yidong
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@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.
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <4D1DB555.5080002@swipnet.se>
2010-12-31 11:23 ` Jan Djärv
[not found] ` <4D1DBD4A.6010303@swipnet.se>
@ 2010-12-31 12:52 ` Eli Zaretskii
[not found] ` <83ei8yayuj.fsf@gnu.org>
3 siblings, 0 replies; 49+ messages in thread
From: Eli Zaretskii @ 2010-12-31 12:52 UTC (permalink / raw)
To: Jan Djärv; +Cc: cyd, emacs-devel, 7517, user.emacs
> Date: Fri, 31 Dec 2010 11:49:57 +0100
> From: Jan Djärv <jan.h.d@swipnet.se>
> Cc: 7517@debbugs.gnu.org, emacs-devel@gnu.org,
> Chong Yidong <cyd@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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <4D1DBD4A.6010303@swipnet.se>
2010-12-31 11:26 ` emacs user
@ 2010-12-31 12:53 ` Eli Zaretskii
[not found] ` <83d3oiaysj.fsf@gnu.org>
2 siblings, 0 replies; 49+ messages in thread
From: Eli Zaretskii @ 2010-12-31 12:53 UTC (permalink / raw)
To: Jan Djärv; +Cc: cyd, 7517, user.emacs, emacs-devel
> Date: Fri, 31 Dec 2010 12:23:54 +0100
> From: Jan Djärv <jan.h.d@swipnet.se>
> Cc: 7517@debbugs.gnu.org, Chong Yidong <cyd@stupidchicken.com>,
> Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@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?
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <83d3oiaysj.fsf@gnu.org>
@ 2010-12-31 13:06 ` emacs user
2010-12-31 13:18 ` Jan Djärv
2010-12-31 13:10 ` Jan Djärv
[not found] ` <4D1DD655.1040809@swipnet.se>
2 siblings, 1 reply; 49+ messages in thread
From: emacs user @ 2010-12-31 13:06 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 7517, cyd, emacs-devel
On Fri, Dec 31, 2010 at 2:53 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 31 Dec 2010 12:23:54 +0100
>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Cc: 7517@debbugs.gnu.org, Chong Yidong <cyd@stupidchicken.com>,
>> Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@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?
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <83d3oiaysj.fsf@gnu.org>
2010-12-31 13:06 ` emacs user
@ 2010-12-31 13:10 ` Jan Djärv
[not found] ` <4D1DD655.1040809@swipnet.se>
2 siblings, 0 replies; 49+ messages in thread
From: Jan Djärv @ 2010-12-31 13:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: cyd, 7517, user.emacs, emacs-devel
Eli Zaretskii skrev 2010-12-31 13.53:
>> Date: Fri, 31 Dec 2010 12:23:54 +0100
>> From: Jan Djärv<jan.h.d@swipnet.se>
>> Cc: 7517@debbugs.gnu.org, Chong Yidong<cyd@stupidchicken.com>,
>> Stefan Monnier<monnier@iro.umontreal.ca>, emacs-devel@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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <83ei8yayuj.fsf@gnu.org>
@ 2010-12-31 13:16 ` Eli Zaretskii
0 siblings, 0 replies; 49+ messages in thread
From: Eli Zaretskii @ 2010-12-31 13:16 UTC (permalink / raw)
To: jan.h.d, cyd, 7517, user.emacs, emacs-devel
> Date: Fri, 31 Dec 2010 14:52:36 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: cyd@stupidchicken.com, 7517@debbugs.gnu.org, user.emacs@gmail.com,
> emacs-devel@gnu.org
>
> Yes, it's a unibyte string encoded in hebrew-iso-8bit.
^^^^^^^^^^^^^^^
AKA 8869-8.
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
2010-12-31 13:06 ` emacs user
@ 2010-12-31 13:18 ` Jan Djärv
0 siblings, 0 replies; 49+ messages in thread
From: Jan Djärv @ 2010-12-31 13:18 UTC (permalink / raw)
To: emacs user; +Cc: 7517, cyd, emacs-devel
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@gnu.org> wrote:
>>> Date: Fri, 31 Dec 2010 12:23:54 +0100
>>> From: Jan Djärv<jan.h.d@swipnet.se>
>>> Cc: 7517@debbugs.gnu.org, Chong Yidong<cyd@stupidchicken.com>,
>>> Stefan Monnier<monnier@iro.umontreal.ca>, emacs-devel@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?
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <4D1DD655.1040809@swipnet.se>
@ 2010-12-31 13:19 ` Eli Zaretskii
[not found] ` <83aajmaxme.fsf@gnu.org>
1 sibling, 0 replies; 49+ messages in thread
From: Eli Zaretskii @ 2010-12-31 13:19 UTC (permalink / raw)
To: Jan Djärv; +Cc: cyd, 7517, user.emacs, emacs-devel
> Date: Fri, 31 Dec 2010 14:10:45 +0100
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: user.emacs@gmail.com, 7517@debbugs.gnu.org, cyd@stupidchicken.com,
> monnier@iro.umontreal.ca, emacs-devel@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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <83aajmaxme.fsf@gnu.org>
@ 2010-12-31 14:22 ` Jan Djärv
[not found] ` <4D1DE740.5060000@swipnet.se>
` (2 subsequent siblings)
3 siblings, 0 replies; 49+ messages in thread
From: Jan Djärv @ 2010-12-31 14:22 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: cyd, 7517, user.emacs, emacs-devel
Eli Zaretskii skrev 2010-12-31 14.19:
>> Date: Fri, 31 Dec 2010 14:10:45 +0100
>> From: Jan Djärv<jan.h.d@swipnet.se>
>> CC: user.emacs@gmail.com, 7517@debbugs.gnu.org, cyd@stupidchicken.com,
>> monnier@iro.umontreal.ca, emacs-devel@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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <4D1DE740.5060000@swipnet.se>
@ 2010-12-31 16:07 ` Eli Zaretskii
[not found] ` <838vz6apu6.fsf@gnu.org>
1 sibling, 0 replies; 49+ messages in thread
From: Eli Zaretskii @ 2010-12-31 16:07 UTC (permalink / raw)
To: Jan Djärv; +Cc: cyd, 7517, user.emacs, emacs-devel
> Date: Fri, 31 Dec 2010 15:22:56 +0100
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: user.emacs@gmail.com, 7517@debbugs.gnu.org, cyd@stupidchicken.com,
> monnier@iro.umontreal.ca, emacs-devel@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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <838vz6apu6.fsf@gnu.org>
@ 2010-12-31 16:09 ` emacs user
2010-12-31 18:57 ` Jan Djärv
[not found] ` <4D1E2787.3030501@swipnet.se>
2 siblings, 0 replies; 49+ messages in thread
From: emacs user @ 2010-12-31 16:09 UTC (permalink / raw)
To: Eli Zaretskii, Uday S. Reddy; +Cc: 7517, cyd, emacs-devel
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@gnu.org> wrote:
>> Date: Fri, 31 Dec 2010 15:22:56 +0100
>> From: Jan Djärv <jan.h.d@swipnet.se>
>> CC: user.emacs@gmail.com, 7517@debbugs.gnu.org, cyd@stupidchicken.com,
>> monnier@iro.umontreal.ca, emacs-devel@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.
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <83aajmaxme.fsf@gnu.org>
2010-12-31 14:22 ` Jan Djärv
[not found] ` <4D1DE740.5060000@swipnet.se>
@ 2010-12-31 16:56 ` Stefan Monnier
[not found] ` <jwv62u9hohk.fsf-monnier+emacs@gnu.org>
3 siblings, 0 replies; 49+ messages in thread
From: Stefan Monnier @ 2010-12-31 16:56 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: cyd, emacs-devel, 7517, user.emacs
> 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
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <jwv62u9hohk.fsf-monnier+emacs@gnu.org>
@ 2010-12-31 17:42 ` emacs user
2010-12-31 22:30 ` Jan Djärv
[not found] ` <4D1E5987.2000502@swipnet.se>
0 siblings, 2 replies; 49+ messages in thread
From: emacs user @ 2010-12-31 17:42 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Uday S. Reddy, cyd, emacs-devel, 7517
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@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
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <838vz6apu6.fsf@gnu.org>
2010-12-31 16:09 ` emacs user
@ 2010-12-31 18:57 ` Jan Djärv
[not found] ` <4D1E2787.3030501@swipnet.se>
2 siblings, 0 replies; 49+ messages in thread
From: Jan Djärv @ 2010-12-31 18:57 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 7517, cyd, emacs-devel, user.emacs
Eli Zaretskii skrev 2010-12-31 17.07:
>> Date: Fri, 31 Dec 2010 15:22:56 +0100
>> From: Jan Djärv<jan.h.d@swipnet.se>
>> CC: user.emacs@gmail.com, 7517@debbugs.gnu.org, cyd@stupidchicken.com,
>> monnier@iro.umontreal.ca, emacs-devel@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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
2010-12-31 17:42 ` emacs user
@ 2010-12-31 22:30 ` Jan Djärv
[not found] ` <4D1E5987.2000502@swipnet.se>
1 sibling, 0 replies; 49+ messages in thread
From: Jan Djärv @ 2010-12-31 22:30 UTC (permalink / raw)
To: emacs user; +Cc: Uday S. Reddy, cyd, emacs-devel, 7517
On Fri, Dec 31, 2010 at 6:56 PM, Stefan Monnier
<monnier@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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <4D1E5987.2000502@swipnet.se>
@ 2010-12-31 23:07 ` Stefan Monnier
[not found] ` <jwvoc81fssl.fsf-monnier+emacs@gnu.org>
` (2 subsequent siblings)
3 siblings, 0 replies; 49+ messages in thread
From: Stefan Monnier @ 2010-12-31 23:07 UTC (permalink / raw)
To: Jan Djärv; +Cc: Uday S. Reddy, emacs user, cyd, emacs-devel, 7517
>>> 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
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <4D1E2787.3030501@swipnet.se>
@ 2011-01-01 3:55 ` Stephen J. Turnbull
0 siblings, 0 replies; 49+ messages in thread
From: Stephen J. Turnbull @ 2011-01-01 3:55 UTC (permalink / raw)
To: Jan Djärv; +Cc: user.emacs, cyd, emacs-devel, 7517
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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <jwvoc81fssl.fsf-monnier+emacs@gnu.org>
@ 2011-01-01 11:57 ` Eli Zaretskii
[not found] ` <83oc80q1k4.fsf@gnu.org>
1 sibling, 0 replies; 49+ messages in thread
From: Eli Zaretskii @ 2011-01-01 11:57 UTC (permalink / raw)
To: Stefan Monnier; +Cc: u.s.reddy, user.emacs, cyd, emacs-devel, 7517
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs user <user.emacs@gmail.com>, Eli Zaretskii <eliz@gnu.org>, 7517@debbugs.gnu.org, cyd@stupidchicken.com, emacs-devel@gnu.org, "Uday S. Reddy" <u.s.reddy@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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <4D1E5987.2000502@swipnet.se>
2010-12-31 23:07 ` Stefan Monnier
[not found] ` <jwvoc81fssl.fsf-monnier+emacs@gnu.org>
@ 2011-01-01 12:00 ` Eli Zaretskii
[not found] ` <83mxnkq1ej.fsf@gnu.org>
3 siblings, 0 replies; 49+ messages in thread
From: Eli Zaretskii @ 2011-01-01 12:00 UTC (permalink / raw)
To: Jan Djärv; +Cc: u.s.reddy, user.emacs, cyd, emacs-devel, 7517
> Date: Fri, 31 Dec 2010 23:30:31 +0100
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: Stefan Monnier <monnier@iro.umontreal.ca>,
> Eli Zaretskii <eliz@gnu.org>,
> 7517@debbugs.gnu.org, cyd@stupidchicken.com, emacs-devel@gnu.org,
> "Uday S. Reddy" <u.s.reddy@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.)
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <83oc80q1k4.fsf@gnu.org>
@ 2011-01-01 12:46 ` emacs user
[not found] ` <AANLkTinKjo8tDKMovGcpuXoHDKqJ_3ik1+fGjGua+bzN@mail.gmail.com>
` (2 subsequent siblings)
3 siblings, 0 replies; 49+ messages in thread
From: emacs user @ 2011-01-01 12:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: u.s.reddy, cyd, emacs-devel, 7517
On Sat, Jan 1, 2011 at 1:57 PM, Eli Zaretskii <eliz@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
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <AANLkTinKjo8tDKMovGcpuXoHDKqJ_3ik1+fGjGua+bzN@mail.gmail.com>
@ 2011-01-01 15:40 ` Eli Zaretskii
[not found] ` <83bp40pr7m.fsf@gnu.org>
1 sibling, 0 replies; 49+ messages in thread
From: Eli Zaretskii @ 2011-01-01 15:40 UTC (permalink / raw)
To: emacs user; +Cc: u.s.reddy, cyd, emacs-devel, 7517
> Date: Sat, 1 Jan 2011 14:46:24 +0200
> From: emacs user <user.emacs@gmail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, jan.h.d@swipnet.se, 7517@debbugs.gnu.org,
> cyd@stupidchicken.com, emacs-devel@gnu.org, u.s.reddy@cs.bham.ac.uk
>
> On Sat, Jan 1, 2011 at 1:57 PM, Eli Zaretskii <eliz@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?
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <83bp40pr7m.fsf@gnu.org>
@ 2011-01-01 17:02 ` Uday S Reddy
[not found] ` <19743.24109.796000.405943@gargle.gargle.HOWL>
2011-01-01 18:34 ` Jan D.
2 siblings, 0 replies; 49+ messages in thread
From: Uday S Reddy @ 2011-01-01 17:02 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: u.s.reddy, 7517, emacs-devel
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <83mxnkq1ej.fsf@gnu.org>
@ 2011-01-01 17:11 ` Stefan Monnier
[not found] ` <jwv7heoa6uu.fsf-monnier+emacs@gnu.org>
1 sibling, 0 replies; 49+ messages in thread
From: Stefan Monnier @ 2011-01-01 17:11 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: u.s.reddy, user.emacs, cyd, emacs-devel, 7517
> 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
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <83oc80q1k4.fsf@gnu.org>
2011-01-01 12:46 ` emacs user
[not found] ` <AANLkTinKjo8tDKMovGcpuXoHDKqJ_3ik1+fGjGua+bzN@mail.gmail.com>
@ 2011-01-01 17:22 ` Stefan Monnier
[not found] ` <jwv1v4wa6re.fsf-monnier+emacs@gnu.org>
3 siblings, 0 replies; 49+ messages in thread
From: Stefan Monnier @ 2011-01-01 17:22 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: u.s.reddy, user.emacs, cyd, emacs-devel, 7517
> 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
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <jwv7heoa6uu.fsf-monnier+emacs@gnu.org>
@ 2011-01-01 18:06 ` Eli Zaretskii
0 siblings, 0 replies; 49+ messages in thread
From: Eli Zaretskii @ 2011-01-01 18:06 UTC (permalink / raw)
To: Stefan Monnier; +Cc: u.s.reddy, user.emacs, cyd, emacs-devel, 7517
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Jan Djärv <jan.h.d@swipnet.se>,
> user.emacs@gmail.com, 7517@debbugs.gnu.org, cyd@stupidchicken.com,
> emacs-devel@gnu.org, u.s.reddy@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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <jwv1v4wa6re.fsf-monnier+emacs@gnu.org>
@ 2011-01-01 18:07 ` Eli Zaretskii
0 siblings, 0 replies; 49+ messages in thread
From: Eli Zaretskii @ 2011-01-01 18:07 UTC (permalink / raw)
To: Stefan Monnier; +Cc: u.s.reddy, user.emacs, cyd, emacs-devel, 7517
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: jan.h.d@swipnet.se, user.emacs@gmail.com, 7517@debbugs.gnu.org, cyd@stupidchicken.com, emacs-devel@gnu.org, u.s.reddy@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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <19743.24109.796000.405943@gargle.gargle.HOWL>
@ 2011-01-01 18:08 ` Eli Zaretskii
0 siblings, 0 replies; 49+ messages in thread
From: Eli Zaretskii @ 2011-01-01 18:08 UTC (permalink / raw)
To: Uday S Reddy; +Cc: u.s.reddy, 7517-done, emacs-devel
> Date: Sat, 1 Jan 2011 17:02:37 +0000
> From: Uday S Reddy <u.s.reddy@cs.bham.ac.uk>
> Cc: 7517@debbugs.gnu.org,
> emacs-devel@gnu.org,
> u.s.reddy@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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <83bp40pr7m.fsf@gnu.org>
2011-01-01 17:02 ` Uday S Reddy
[not found] ` <19743.24109.796000.405943@gargle.gargle.HOWL>
@ 2011-01-01 18:34 ` Jan D.
2011-01-02 14:02 ` Chong Yidong
[not found] ` <87r5cvz9ms.fsf@stupidchicken.com>
2 siblings, 2 replies; 49+ messages in thread
From: Jan D. @ 2011-01-01 18:34 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: u.s.reddy, emacs user, cyd, emacs-devel, 7517
Eli Zaretskii skrev 2011-01-01 16:40:
> right?
>
> I guess this bug report can be closed now. Any objections?
No.
Jan D.
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
2011-01-01 18:34 ` Jan D.
@ 2011-01-02 14:02 ` Chong Yidong
[not found] ` <87r5cvz9ms.fsf@stupidchicken.com>
1 sibling, 0 replies; 49+ messages in thread
From: Chong Yidong @ 2011-01-02 14:02 UTC (permalink / raw)
To: Jan D.; +Cc: u.s.reddy, emacs user, emacs-devel, 7517
"Jan D." <jan.h.d@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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X
[not found] ` <87r5cvz9ms.fsf@stupidchicken.com>
@ 2011-01-03 21:34 ` Jan Djärv
0 siblings, 0 replies; 49+ messages in thread
From: Jan Djärv @ 2011-01-03 21:34 UTC (permalink / raw)
To: Chong Yidong; +Cc: u.s.reddy, emacs user, emacs-devel, 7517
Done.
Jan D.
Chong Yidong skrev 2011-01-02 15.02:
> "Jan D."<jan.h.d@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.
^ permalink raw reply [flat|nested] 49+ messages in thread
end of thread, other threads:[~2011-01-03 21:34 UTC | newest]
Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-29 14:22 bug#7517: 24.0.50; repeated crash under Mac OS X emacs user
2010-12-17 11:47 ` Chong Yidong
2010-12-17 23:07 ` emacs user
2010-12-17 23:42 ` emacs user
[not found] ` <AANLkTinQHfFXazEbf+qxtz5+MfKcaXQLN18nPnyQMj8X@mail.gmail.com>
2010-12-26 18:43 ` emacs user
2010-12-29 4:29 ` Chong Yidong
[not found] ` <87vd2dyzfj.fsf@stupidchicken.com>
2010-12-29 11:59 ` Jan Djärv
[not found] ` <4D1B22A1.6080202@swipnet.se>
2010-12-29 12:21 ` Jan Djärv
[not found] ` <4D1B27AF.7010701@swipnet.se>
2010-12-29 15:41 ` Stefan Monnier
[not found] ` <jwvpqskio2r.fsf-monnier+emacs@gnu.org>
2010-12-29 16:06 ` emacs user
2010-12-30 11:35 ` Jan Djärv
[not found] ` <4D1C6E7D.2040300@swipnet.se>
2010-12-30 14:20 ` emacs user
2010-12-30 22:02 ` Jan Djärv
[not found] ` <4D1D0172.8080404@swipnet.se>
2010-12-31 6:11 ` emacs user
2010-12-31 6:12 ` emacs user
2010-12-31 8:18 ` Eli Zaretskii
2010-12-31 10:49 ` Jan Djärv
[not found] ` <83ipyabbj1.fsf@gnu.org>
2010-12-31 11:16 ` emacs user
[not found] ` <4D1DB555.5080002@swipnet.se>
2010-12-31 11:23 ` Jan Djärv
[not found] ` <4D1DBD4A.6010303@swipnet.se>
2010-12-31 11:26 ` emacs user
2010-12-31 12:53 ` Eli Zaretskii
[not found] ` <83d3oiaysj.fsf@gnu.org>
2010-12-31 13:06 ` emacs user
2010-12-31 13:18 ` Jan Djärv
2010-12-31 13:10 ` Jan Djärv
[not found] ` <4D1DD655.1040809@swipnet.se>
2010-12-31 13:19 ` Eli Zaretskii
[not found] ` <83aajmaxme.fsf@gnu.org>
2010-12-31 14:22 ` Jan Djärv
[not found] ` <4D1DE740.5060000@swipnet.se>
2010-12-31 16:07 ` Eli Zaretskii
[not found] ` <838vz6apu6.fsf@gnu.org>
2010-12-31 16:09 ` emacs user
2010-12-31 18:57 ` Jan Djärv
[not found] ` <4D1E2787.3030501@swipnet.se>
2011-01-01 3:55 ` Stephen J. Turnbull
2010-12-31 16:56 ` Stefan Monnier
[not found] ` <jwv62u9hohk.fsf-monnier+emacs@gnu.org>
2010-12-31 17:42 ` emacs user
2010-12-31 22:30 ` Jan Djärv
[not found] ` <4D1E5987.2000502@swipnet.se>
2010-12-31 23:07 ` Stefan Monnier
[not found] ` <jwvoc81fssl.fsf-monnier+emacs@gnu.org>
2011-01-01 11:57 ` Eli Zaretskii
[not found] ` <83oc80q1k4.fsf@gnu.org>
2011-01-01 12:46 ` emacs user
[not found] ` <AANLkTinKjo8tDKMovGcpuXoHDKqJ_3ik1+fGjGua+bzN@mail.gmail.com>
2011-01-01 15:40 ` Eli Zaretskii
[not found] ` <83bp40pr7m.fsf@gnu.org>
2011-01-01 17:02 ` Uday S Reddy
[not found] ` <19743.24109.796000.405943@gargle.gargle.HOWL>
2011-01-01 18:08 ` Eli Zaretskii
2011-01-01 18:34 ` Jan D.
2011-01-02 14:02 ` Chong Yidong
[not found] ` <87r5cvz9ms.fsf@stupidchicken.com>
2011-01-03 21:34 ` Jan Djärv
2011-01-01 17:22 ` Stefan Monnier
[not found] ` <jwv1v4wa6re.fsf-monnier+emacs@gnu.org>
2011-01-01 18:07 ` Eli Zaretskii
2011-01-01 12:00 ` Eli Zaretskii
[not found] ` <83mxnkq1ej.fsf@gnu.org>
2011-01-01 17:11 ` Stefan Monnier
[not found] ` <jwv7heoa6uu.fsf-monnier+emacs@gnu.org>
2011-01-01 18:06 ` Eli Zaretskii
2010-12-31 12:52 ` Eli Zaretskii
[not found] ` <83ei8yayuj.fsf@gnu.org>
2010-12-31 13:16 ` Eli Zaretskii
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).