* 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; 95+ 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] 95+ 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; 95+ 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] 95+ 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; 95+ 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] 95+ 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; 95+ 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] 95+ messages in thread
[parent not found: <AANLkTinQHfFXazEbf+qxtz5+MfKcaXQLN18nPnyQMj8X@mail.gmail.com>]
* 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 2010-12-29 4:29 ` Chong Yidong 0 siblings, 2 replies; 95+ 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] 95+ messages in thread
* Re: 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 2010-12-29 11:59 ` Jan Djärv 2010-12-29 11:59 ` Jan Djärv 2010-12-29 4:29 ` Chong Yidong 1 sibling, 2 replies; 95+ 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-29 4:29 ` Chong Yidong @ 2010-12-29 11:59 ` Jan Djärv 2010-12-29 11:59 ` Jan Djärv 1 sibling, 0 replies; 95+ 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-29 4:29 ` Chong Yidong 2010-12-29 11:59 ` Jan Djärv @ 2010-12-29 11:59 ` Jan Djärv 2010-12-29 12:21 ` Jan Djärv 2010-12-29 12:21 ` Jan Djärv 1 sibling, 2 replies; 95+ 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-29 11:59 ` Jan Djärv @ 2010-12-29 12:21 ` Jan Djärv 2010-12-29 12:21 ` Jan Djärv 1 sibling, 0 replies; 95+ 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-29 11:59 ` Jan Djärv 2010-12-29 12:21 ` Jan Djärv @ 2010-12-29 12:21 ` Jan Djärv 2010-12-29 15:41 ` Stefan Monnier 2010-12-29 15:41 ` Stefan Monnier 1 sibling, 2 replies; 95+ 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-29 12:21 ` Jan Djärv @ 2010-12-29 15:41 ` Stefan Monnier 2010-12-29 16:06 ` emacs user 2010-12-29 15:41 ` Stefan Monnier 1 sibling, 1 reply; 95+ messages in thread From: Stefan Monnier @ 2010-12-29 15:41 UTC (permalink / raw) To: Jan Djärv; +Cc: Chong Yidong, emacs-devel, 7517, emacs user > 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-29 15:41 ` Stefan Monnier @ 2010-12-29 16:06 ` emacs user 2010-12-30 11:35 ` Jan Djärv 2010-12-30 11:35 ` Jan Djärv 0 siblings, 2 replies; 95+ 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] 95+ messages in thread
* Re: 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 2010-12-30 14:20 ` emacs user 2010-12-30 11:35 ` Jan Djärv 1 sibling, 1 reply; 95+ messages in thread From: Jan Djärv @ 2010-12-30 11:35 UTC (permalink / raw) To: emacs user; +Cc: 7517, Chong Yidong, Stefan Monnier, emacs-devel 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-30 11:35 ` Jan Djärv @ 2010-12-30 14:20 ` emacs user 2010-12-30 22:02 ` Jan Djärv 2010-12-30 22:02 ` Jan Djärv 0 siblings, 2 replies; 95+ 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] 95+ 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 2010-12-30 22:02 ` Jan Djärv 1 sibling, 0 replies; 95+ 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] 95+ messages in thread
* Re: 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 @ 2010-12-30 22:02 ` Jan Djärv 2010-12-31 6:11 ` emacs user 2010-12-31 6:12 ` emacs user 1 sibling, 2 replies; 95+ messages in thread From: Jan Djärv @ 2010-12-30 22:02 UTC (permalink / raw) To: emacs user; +Cc: 7517, Chong Yidong, Stefan Monnier, emacs-devel 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-30 22:02 ` Jan Djärv @ 2010-12-31 6:11 ` emacs user 2010-12-31 6:12 ` emacs user 1 sibling, 0 replies; 95+ 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-30 22:02 ` Jan Djärv 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; 95+ 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] 95+ 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 8:18 ` Eli Zaretskii ` (2 subsequent siblings) 3 siblings, 0 replies; 95+ 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] 95+ messages in thread
* Re: 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 8:18 ` Eli Zaretskii 2010-12-31 11:16 ` emacs user 2010-12-31 10:49 ` Jan Djärv 2010-12-31 10:49 ` Jan Djärv 3 siblings, 1 reply; 95+ messages in thread From: Eli Zaretskii @ 2010-12-31 8:18 UTC (permalink / raw) To: emacs user; +Cc: 7517, jan.h.d, 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 8:18 ` Eli Zaretskii @ 2010-12-31 11:16 ` emacs user 0 siblings, 0 replies; 95+ 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] 95+ 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 8:18 ` Eli Zaretskii @ 2010-12-31 10:49 ` Jan Djärv 2010-12-31 10:49 ` Jan Djärv 3 siblings, 0 replies; 95+ 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 6:12 ` emacs user ` (2 preceding siblings ...) 2010-12-31 10:49 ` Jan Djärv @ 2010-12-31 10:49 ` Jan Djärv 2010-12-31 11:23 ` Jan Djärv ` (3 more replies) 3 siblings, 4 replies; 95+ messages in thread From: Jan Djärv @ 2010-12-31 10:49 UTC (permalink / raw) To: emacs user; +Cc: 7517, Chong Yidong, Stefan Monnier, emacs-devel 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 10:49 ` Jan Djärv @ 2010-12-31 11:23 ` Jan Djärv 2010-12-31 11:26 ` emacs user ` (2 more replies) 2010-12-31 11:23 ` Jan Djärv ` (2 subsequent siblings) 3 siblings, 3 replies; 95+ messages in thread From: Jan Djärv @ 2010-12-31 11:23 UTC (permalink / raw) To: emacs user; +Cc: 7517, Chong Yidong, Stefan Monnier, emacs-devel 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 11:23 ` Jan Djärv @ 2010-12-31 11:26 ` emacs user 2010-12-31 12:53 ` Eli Zaretskii 2010-12-31 12:53 ` Eli Zaretskii 2 siblings, 0 replies; 95+ 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 11:23 ` Jan Djärv 2010-12-31 11:26 ` emacs user @ 2010-12-31 12:53 ` Eli Zaretskii 2010-12-31 13:06 ` emacs user ` (2 more replies) 2010-12-31 12:53 ` Eli Zaretskii 2 siblings, 3 replies; 95+ messages in thread From: Eli Zaretskii @ 2010-12-31 12:53 UTC (permalink / raw) To: Jan Djärv; +Cc: cyd, 7517, emacs-devel, user.emacs, monnier > 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 12:53 ` Eli Zaretskii @ 2010-12-31 13:06 ` emacs user 2010-12-31 13:18 ` Jan Djärv 2010-12-31 13:18 ` Jan Djärv 2010-12-31 13:10 ` Jan Djärv 2010-12-31 13:10 ` Jan Djärv 2 siblings, 2 replies; 95+ 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] 95+ messages in thread
* Re: 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 2010-12-31 13:18 ` Jan Djärv 1 sibling, 0 replies; 95+ messages in thread From: Jan Djärv @ 2010-12-31 13:18 UTC (permalink / raw) To: emacs user; +Cc: cyd, Eli Zaretskii, emacs-devel, 7517, monnier 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] 95+ 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 @ 2010-12-31 13:18 ` Jan Djärv 1 sibling, 0 replies; 95+ 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 12:53 ` Eli Zaretskii 2010-12-31 13:06 ` emacs user @ 2010-12-31 13:10 ` Jan Djärv 2010-12-31 13:19 ` Eli Zaretskii 2010-12-31 13:19 ` Eli Zaretskii 2010-12-31 13:10 ` Jan Djärv 2 siblings, 2 replies; 95+ messages in thread From: Jan Djärv @ 2010-12-31 13:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, 7517, emacs-devel, user.emacs, monnier 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 13:10 ` Jan Djärv @ 2010-12-31 13:19 ` Eli Zaretskii 2010-12-31 14:22 ` Jan Djärv ` (3 more replies) 2010-12-31 13:19 ` Eli Zaretskii 1 sibling, 4 replies; 95+ messages in thread From: Eli Zaretskii @ 2010-12-31 13:19 UTC (permalink / raw) To: Jan Djärv; +Cc: cyd, 7517, emacs-devel, user.emacs, monnier > 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 13:19 ` Eli Zaretskii @ 2010-12-31 14:22 ` Jan Djärv 2010-12-31 14:22 ` Jan Djärv ` (2 subsequent siblings) 3 siblings, 0 replies; 95+ 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 13:19 ` Eli Zaretskii 2010-12-31 14:22 ` Jan Djärv @ 2010-12-31 14:22 ` Jan Djärv 2010-12-31 16:07 ` Eli Zaretskii 2010-12-31 16:07 ` Eli Zaretskii 2010-12-31 16:56 ` Stefan Monnier 2010-12-31 16:56 ` Stefan Monnier 3 siblings, 2 replies; 95+ messages in thread From: Jan Djärv @ 2010-12-31 14:22 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, 7517, emacs-devel, user.emacs, monnier 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 14:22 ` Jan Djärv @ 2010-12-31 16:07 ` Eli Zaretskii 2010-12-31 16:07 ` Eli Zaretskii 1 sibling, 0 replies; 95+ 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 14:22 ` Jan Djärv 2010-12-31 16:07 ` Eli Zaretskii @ 2010-12-31 16:07 ` Eli Zaretskii 2010-12-31 16:09 ` emacs user ` (3 more replies) 1 sibling, 4 replies; 95+ messages in thread From: Eli Zaretskii @ 2010-12-31 16:07 UTC (permalink / raw) To: Jan Djärv; +Cc: cyd, 7517, emacs-devel, user.emacs, monnier > 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 16:07 ` Eli Zaretskii @ 2010-12-31 16:09 ` emacs user 2010-12-31 16:09 ` emacs user ` (2 subsequent siblings) 3 siblings, 0 replies; 95+ messages in thread From: emacs user @ 2010-12-31 16:09 UTC (permalink / raw) To: Eli Zaretskii, Uday S. Reddy Cc: 7517, Jan Djärv, emacs-devel, cyd, monnier 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 16:07 ` Eli Zaretskii 2010-12-31 16:09 ` emacs user @ 2010-12-31 16:09 ` emacs user 2010-12-31 18:57 ` Jan Djärv 2010-12-31 18:57 ` Jan Djärv 3 siblings, 0 replies; 95+ 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 16:07 ` Eli Zaretskii 2010-12-31 16:09 ` emacs user 2010-12-31 16:09 ` emacs user @ 2010-12-31 18:57 ` Jan Djärv 2011-01-01 3:55 ` Stephen J. Turnbull 2011-01-01 3:55 ` Stephen J. Turnbull 2010-12-31 18:57 ` Jan Djärv 3 siblings, 2 replies; 95+ messages in thread From: Jan Djärv @ 2010-12-31 18:57 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, monnier, 7517, user.emacs, emacs-devel 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 18:57 ` Jan Djärv @ 2011-01-01 3:55 ` Stephen J. Turnbull 2011-01-01 3:55 ` Stephen J. Turnbull 1 sibling, 0 replies; 95+ 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 18:57 ` Jan Djärv 2011-01-01 3:55 ` Stephen J. Turnbull @ 2011-01-01 3:55 ` Stephen J. Turnbull 1 sibling, 0 replies; 95+ 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, monnier, 7517, Eli Zaretskii 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 16:07 ` Eli Zaretskii ` (2 preceding siblings ...) 2010-12-31 18:57 ` Jan Djärv @ 2010-12-31 18:57 ` Jan Djärv 3 siblings, 0 replies; 95+ 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 13:19 ` Eli Zaretskii 2010-12-31 14:22 ` Jan Djärv 2010-12-31 14:22 ` Jan Djärv @ 2010-12-31 16:56 ` Stefan Monnier 2010-12-31 17:42 ` emacs user 2010-12-31 16:56 ` Stefan Monnier 3 siblings, 1 reply; 95+ messages in thread From: Stefan Monnier @ 2010-12-31 16:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, 7517, Jan Djärv, user.emacs, emacs-devel > 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 16:56 ` Stefan Monnier @ 2010-12-31 17:42 ` emacs user 2010-12-31 22:30 ` Jan Djärv 2010-12-31 22:30 ` Jan Djärv 0 siblings, 2 replies; 95+ 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] 95+ messages in thread
* Re: 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 2010-12-31 23:07 ` Stefan Monnier ` (3 more replies) 2010-12-31 22:30 ` Jan Djärv 1 sibling, 4 replies; 95+ 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, Stefan Monnier, 7517, Eli Zaretskii 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 22:30 ` Jan Djärv @ 2010-12-31 23:07 ` Stefan Monnier 2010-12-31 23:07 ` Stefan Monnier ` (2 subsequent siblings) 3 siblings, 0 replies; 95+ 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 22:30 ` Jan Djärv 2010-12-31 23:07 ` Stefan Monnier @ 2010-12-31 23:07 ` Stefan Monnier 2011-01-01 11:57 ` Eli Zaretskii 2011-01-01 11:57 ` Eli Zaretskii 2011-01-01 12:00 ` Eli Zaretskii 2011-01-01 12:00 ` Eli Zaretskii 3 siblings, 2 replies; 95+ 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, Eli Zaretskii >>> 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 23:07 ` Stefan Monnier @ 2011-01-01 11:57 ` Eli Zaretskii 2011-01-01 12:46 ` emacs user ` (3 more replies) 2011-01-01 11:57 ` Eli Zaretskii 1 sibling, 4 replies; 95+ 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, jan.h.d > 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-01 11:57 ` Eli Zaretskii @ 2011-01-01 12:46 ` emacs user 2011-01-01 12:46 ` emacs user ` (2 subsequent siblings) 3 siblings, 0 replies; 95+ 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-01 11:57 ` Eli Zaretskii 2011-01-01 12:46 ` emacs user @ 2011-01-01 12:46 ` emacs user 2011-01-01 15:40 ` Eli Zaretskii 2011-01-01 15:40 ` Eli Zaretskii 2011-01-01 17:22 ` Stefan Monnier 2011-01-01 17:22 ` Stefan Monnier 3 siblings, 2 replies; 95+ messages in thread From: emacs user @ 2011-01-01 12:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: u.s.reddy, cyd, emacs-devel, Stefan Monnier, 7517, jan.h.d 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-01 12:46 ` emacs user @ 2011-01-01 15:40 ` Eli Zaretskii 2011-01-01 17:02 ` Uday S Reddy ` (2 more replies) 2011-01-01 15:40 ` Eli Zaretskii 1 sibling, 3 replies; 95+ messages in thread From: Eli Zaretskii @ 2011-01-01 15:40 UTC (permalink / raw) To: emacs user; +Cc: u.s.reddy, cyd, emacs-devel, monnier, 7517, jan.h.d > 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-01 15:40 ` Eli Zaretskii @ 2011-01-01 17:02 ` Uday S Reddy 2011-01-01 18:08 ` Eli Zaretskii 2011-01-01 18:08 ` Eli Zaretskii 2011-01-01 17:02 ` Uday S Reddy 2011-01-01 18:34 ` Jan D. 2 siblings, 2 replies; 95+ 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-01 17:02 ` Uday S Reddy @ 2011-01-01 18:08 ` Eli Zaretskii 2011-01-01 18:08 ` Eli Zaretskii 1 sibling, 0 replies; 95+ 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-01 17:02 ` Uday S Reddy 2011-01-01 18:08 ` Eli Zaretskii @ 2011-01-01 18:08 ` Eli Zaretskii 1 sibling, 0 replies; 95+ 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-01 15:40 ` Eli Zaretskii 2011-01-01 17:02 ` Uday S Reddy @ 2011-01-01 17:02 ` Uday S Reddy 2011-01-01 18:34 ` Jan D. 2 siblings, 0 replies; 95+ 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-01 15:40 ` Eli Zaretskii 2011-01-01 17:02 ` Uday S Reddy 2011-01-01 17:02 ` Uday S Reddy @ 2011-01-01 18:34 ` Jan D. 2011-01-02 14:02 ` Chong Yidong 2011-01-02 14:02 ` Chong Yidong 2 siblings, 2 replies; 95+ 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] 95+ messages in thread
* Re: 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 2011-01-03 21:34 ` Jan Djärv 2011-01-03 21:34 ` Jan Djärv 2011-01-02 14:02 ` Chong Yidong 1 sibling, 2 replies; 95+ 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, monnier, 7517, Eli Zaretskii "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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-02 14:02 ` Chong Yidong @ 2011-01-03 21:34 ` Jan Djärv 2011-01-03 21:34 ` Jan Djärv 1 sibling, 0 replies; 95+ 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-02 14:02 ` Chong Yidong 2011-01-03 21:34 ` Jan Djärv @ 2011-01-03 21:34 ` Jan Djärv 1 sibling, 0 replies; 95+ 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, monnier, 7517, Eli Zaretskii 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] 95+ 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 @ 2011-01-02 14:02 ` Chong Yidong 1 sibling, 0 replies; 95+ 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-01 12:46 ` emacs user 2011-01-01 15:40 ` Eli Zaretskii @ 2011-01-01 15:40 ` Eli Zaretskii 1 sibling, 0 replies; 95+ 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-01 11:57 ` Eli Zaretskii 2011-01-01 12:46 ` emacs user 2011-01-01 12:46 ` emacs user @ 2011-01-01 17:22 ` Stefan Monnier 2011-01-01 18:07 ` Eli Zaretskii 2011-01-01 18:07 ` Eli Zaretskii 2011-01-01 17:22 ` Stefan Monnier 3 siblings, 2 replies; 95+ 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, jan.h.d > 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-01 17:22 ` Stefan Monnier @ 2011-01-01 18:07 ` Eli Zaretskii 2011-01-01 18:07 ` Eli Zaretskii 1 sibling, 0 replies; 95+ 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, jan.h.d > 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-01 17:22 ` Stefan Monnier 2011-01-01 18:07 ` Eli Zaretskii @ 2011-01-01 18:07 ` Eli Zaretskii 1 sibling, 0 replies; 95+ 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-01 11:57 ` Eli Zaretskii ` (2 preceding siblings ...) 2011-01-01 17:22 ` Stefan Monnier @ 2011-01-01 17:22 ` Stefan Monnier 3 siblings, 0 replies; 95+ 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 23:07 ` Stefan Monnier 2011-01-01 11:57 ` Eli Zaretskii @ 2011-01-01 11:57 ` Eli Zaretskii 1 sibling, 0 replies; 95+ 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 22:30 ` Jan Djärv 2010-12-31 23:07 ` Stefan Monnier 2010-12-31 23:07 ` Stefan Monnier @ 2011-01-01 12:00 ` Eli Zaretskii 2011-01-01 17:11 ` Stefan Monnier 2011-01-01 17:11 ` Stefan Monnier 2011-01-01 12:00 ` Eli Zaretskii 3 siblings, 2 replies; 95+ 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, monnier, 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-01 12:00 ` Eli Zaretskii @ 2011-01-01 17:11 ` Stefan Monnier 2011-01-01 17:11 ` Stefan Monnier 1 sibling, 0 replies; 95+ 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-01 12:00 ` Eli Zaretskii 2011-01-01 17:11 ` Stefan Monnier @ 2011-01-01 17:11 ` Stefan Monnier 2011-01-01 18:06 ` Eli Zaretskii 2011-01-01 18:06 ` Eli Zaretskii 1 sibling, 2 replies; 95+ 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, Jan Djärv > 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-01 17:11 ` Stefan Monnier @ 2011-01-01 18:06 ` Eli Zaretskii 2011-01-01 18:06 ` Eli Zaretskii 1 sibling, 0 replies; 95+ 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, jan.h.d > 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-01 17:11 ` Stefan Monnier 2011-01-01 18:06 ` Eli Zaretskii @ 2011-01-01 18:06 ` Eli Zaretskii 2011-01-01 22:43 ` Uday S Reddy 1 sibling, 1 reply; 95+ 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-01 18:06 ` Eli Zaretskii @ 2011-01-01 22:43 ` Uday S Reddy 2011-01-02 4:03 ` Eli Zaretskii 0 siblings, 1 reply; 95+ messages in thread From: Uday S Reddy @ 2011-01-01 22:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: user.emacs, emacs-devel On 1/1/2011 6:06 PM, Eli Zaretskii wrote: > > As we see from the OP's last message, the email header was actually > RFC2047-correct. It turns out that the header wasn't processed correctly because Emacs doesn't show any coding system with the mime-charset property of "iso-8859-8-i". There is in fact a coding system with an identical name. But its mime-charset property is given as "iso-8859-8". Is there something subtle here that I don't understand? Cheers, Uday ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-01 22:43 ` Uday S Reddy @ 2011-01-02 4:03 ` Eli Zaretskii 2011-01-02 20:43 ` Uday S Reddy 0 siblings, 1 reply; 95+ messages in thread From: Eli Zaretskii @ 2011-01-02 4:03 UTC (permalink / raw) To: Uday S Reddy; +Cc: user.emacs, emacs-devel > Date: Sat, 01 Jan 2011 22:43:34 +0000 > From: Uday S Reddy <u.s.reddy@cs.bham.ac.uk> > CC: user.emacs@gmail.com, emacs-devel@gnu.org > > It turns out that the header wasn't processed correctly because Emacs > doesn't show any coding system with the mime-charset property of > "iso-8859-8-i". There is in fact a coding system with an identical > name. But its mime-charset property is given as "iso-8859-8". > > Is there something subtle here that I don't understand? The only subtlety here is that iso-8859-8-i is a coding-system-alias of iso-8859-8. Does that help to resolve the issue? ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-02 4:03 ` Eli Zaretskii @ 2011-01-02 20:43 ` Uday S Reddy 2011-01-02 22:06 ` Jan Djärv ` (2 more replies) 0 siblings, 3 replies; 95+ messages in thread From: Uday S Reddy @ 2011-01-02 20:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Uday S Reddy, user.emacs, emacs-devel Eli Zaretskii writes: > > It turns out that the header wasn't processed correctly because Emacs > > doesn't show any coding system with the mime-charset property of > > "iso-8859-8-i". There is in fact a coding system with an identical > > name. But its mime-charset property is given as "iso-8859-8". > > The only subtlety here is that iso-8859-8-i is a coding-system-alias > of iso-8859-8. Does that help to resolve the issue? I have now given up on using the mime-charset property to search for coding systems because of the too many aliases going on. However, it seems that all the coding systems have aliases that correspond to MIME charset names. So, I am using that to find the right coding system. This has corrected the buffer name problem. However, OP reports that the frame title says "bad coding" or some such incantation, even though the buffer name shows up correctly inside Emacs. Perhaps it is a problem in the interface between Emacs and the OS? Cheers, Uday ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-02 20:43 ` Uday S Reddy @ 2011-01-02 22:06 ` Jan Djärv 2011-01-03 4:59 ` Uday S Reddy 2011-01-02 22:08 ` Eli Zaretskii 2011-01-03 0:27 ` Stefan Monnier 2 siblings, 1 reply; 95+ messages in thread From: Jan Djärv @ 2011-01-02 22:06 UTC (permalink / raw) To: Uday S Reddy Cc: Uday S Reddy, Eli Zaretskii, user.emacs@gmail.com, emacs-devel@gnu.org 2 jan 2011 kl. 21:43 skrev Uday S Reddy <u.s.reddy@cs.bham.ac.uk>: > Eli Zaretskii writes: > >>> It turns out that the header wasn't processed correctly because Emacs >>> doesn't show any coding system with the mime-charset property of >>> "iso-8859-8-i". There is in fact a coding system with an identical >>> name. But its mime-charset property is given as "iso-8859-8". >> >> The only subtlety here is that iso-8859-8-i is a coding-system-alias >> of iso-8859-8. Does that help to resolve the issue? > > I have now given up on using the mime-charset property to search for > coding systems because of the too many aliases going on. However, it > seems that all the coding systems have aliases that correspond to MIME > charset names. So, I am using that to find the right coding system. > This has corrected the buffer name problem. > > However, OP reports that the frame title says "bad coding" or some > such incantation, even though the buffer name shows up correctly > inside Emacs. Perhaps it is a problem in the interface between Emacs > and the OS? Exactly how do you show the buffer name within Emacs? Does the buffername have any coding that isn't UTF-8? Jan D. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-02 22:06 ` Jan Djärv @ 2011-01-03 4:59 ` Uday S Reddy 2011-01-03 8:10 ` emacs user 0 siblings, 1 reply; 95+ messages in thread From: Uday S Reddy @ 2011-01-03 4:59 UTC (permalink / raw) To: Jan Djärv Cc: Uday S Reddy, Eli Zaretskii, user.emacs@gmail.com, emacs-devel@gnu.org Jan Djärv writes: > Exactly how do you show the buffer name within Emacs? You mean how do we show it in the frame title? We don't do anything special. Emacs seems to put the buffer name in the frame title automatically. If you do (generate-new-buffer "שולח דואר אלקטרוני") and switch to that buffer inside Emacs, you will probably find that the buffer name shows correctly in the mode line, but it doesn't show correctly in the fram etitle. > Does the buffername have any coding that isn't UTF-8? I don't know what that means! There is no coding now. The buffer name is just an Emacs multibyte string. Cheers, Uday ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-03 4:59 ` Uday S Reddy @ 2011-01-03 8:10 ` emacs user 0 siblings, 0 replies; 95+ messages in thread From: emacs user @ 2011-01-03 8:10 UTC (permalink / raw) To: Uday S Reddy; +Cc: Eli Zaretskii, Jan Djärv, emacs-devel@gnu.org [-- Attachment #1: Type: text/plain, Size: 1016 bytes --] On Mon, Jan 3, 2011 at 6:59 AM, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote: > Jan Djärv writes: > >> Exactly how do you show the buffer name within Emacs? > > You mean how do we show it in the frame title? We don't do anything > special. Emacs seems to put the buffer name in the frame title > automatically. > > If you do > > (generate-new-buffer "שולח דואר אלקטרוני") > > and switch to that buffer inside Emacs, you will probably find that > the buffer name shows correctly in the mode line, but it doesn't show > correctly in the fram etitle. > >> Does the buffername have any coding that isn't UTF-8? > > I don't know what that means! There is no coding now. The buffer > name is just an Emacs multibyte string. > > Cheers, > Uday > I am attaching a snapshot of the emacs frame. once I do vm-discard-message-cache as uday suggested, the frame title is fine now. (Uday, it seems that when I then exit vm and start it again, the problem returns). E [-- Attachment #2: t.tiff --] [-- Type: image/tiff, Size: 77322 bytes --] ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-02 20:43 ` Uday S Reddy 2011-01-02 22:06 ` Jan Djärv @ 2011-01-02 22:08 ` Eli Zaretskii 2011-01-03 4:50 ` Uday S Reddy 2011-01-03 0:27 ` Stefan Monnier 2 siblings, 1 reply; 95+ messages in thread From: Eli Zaretskii @ 2011-01-02 22:08 UTC (permalink / raw) To: Uday S Reddy; +Cc: user.emacs, emacs-devel > Date: Sun, 2 Jan 2011 20:43:17 +0000 > From: Uday S Reddy <u.s.reddy@cs.bham.ac.uk> > Cc: Uday S Reddy <u.s.reddy@cs.bham.ac.uk>, > user.emacs@gmail.com, > emacs-devel@gnu.org > > > The only subtlety here is that iso-8859-8-i is a coding-system-alias > > of iso-8859-8. Does that help to resolve the issue? > > I have now given up on using the mime-charset property to search for > coding systems because of the too many aliases going on. However, it > seems that all the coding systems have aliases that correspond to MIME > charset names. So, I am using that to find the right coding system. Why, doesn't (coding-system-get FOO :mime-charset) work for you, or isn't TRT in this case? > However, OP reports that the frame title says "bad coding" or some > such incantation, even though the buffer name shows up correctly > inside Emacs. Perhaps it is a problem in the interface between Emacs > and the OS? No, that's our way to defend ourselves against buffer names that are unibyte strings, to avoid a crash that was the trigger for this bug. If the unibyte buffer name is now solved, the "bad coding" text will never show up. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-02 22:08 ` Eli Zaretskii @ 2011-01-03 4:50 ` Uday S Reddy 2011-01-03 13:10 ` Eli Zaretskii 0 siblings, 1 reply; 95+ messages in thread From: Uday S Reddy @ 2011-01-03 4:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Uday S Reddy, user.emacs, emacs-devel Eli Zaretskii writes: > Why, doesn't > > (coding-system-get FOO :mime-charset) > > work for you, or isn't TRT in this case? The FOO in this case is a coding-system? But VM doesn't know what coding-system to use. It has to find the coding-system based on the mime-charset. It received a string that is encoded in the MIME charset "iso-8859-8-i". It tried to find an Emacs coding system that had this mime-charset property. But there wasn't any. So it gave up. That was the problem the OP ran into orignally. Note that (coding-system "iso-8859-8-i" :mime-charset) returns "iso-8859-8". What I am doing now is to see if there is a coding-system with the same name as the mime-charset. That works. So, as long as you continue to define aliases for coding-systems that correspond to mime-charset names, we will be fine. When I don't find a coding-system with the given name, I am using 'undecided, which is what I think you reocmmended. This at least gets us out of the unibyte string problem, even though what is produced is normally gibberish. > > However, OP reports that the frame title says "bad coding" or some > > such incantation, even though the buffer name shows up correctly > > inside Emacs. Perhaps it is a problem in the interface between Emacs > > and the OS? > > No, that's our way to defend ourselves against buffer names that are > unibyte strings, to avoid a crash that was the trigger for this bug. > If the unibyte buffer name is now solved, the "bad coding" text will > never show up. That is what I thought. But the OP is getting the "bad coding" text even if a multibyte string is used as the buffer name. So, perhaps there is a still problem there. The problem should show up if you do (generate-new-buffer "שולח דואר אלקטרוני") and switch to that buffer Emacs. (I hope my string makes it through VM + mail-mode without corruption!) Cheers, Uday ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-03 4:50 ` Uday S Reddy @ 2011-01-03 13:10 ` Eli Zaretskii 2011-01-03 21:07 ` Jan Djärv 0 siblings, 1 reply; 95+ messages in thread From: Eli Zaretskii @ 2011-01-03 13:10 UTC (permalink / raw) To: Uday S Reddy; +Cc: u.s.reddy, user.emacs, emacs-devel > Date: Mon, 3 Jan 2011 04:50:45 +0000 > From: Uday S Reddy <u.s.reddy@cs.bham.ac.uk> > Cc: Uday S Reddy <u.s.reddy@cs.bham.ac.uk>, > user.emacs@gmail.com, > emacs-devel@gnu.org > > Eli Zaretskii writes: > > > Why, doesn't > > > > (coding-system-get FOO :mime-charset) > > > > work for you, or isn't TRT in this case? > > The FOO in this case is a coding-system? Yes. > But VM doesn't know what coding-system to use. It has to find the > coding-system based on the mime-charset. > > It received a string that is encoded in the MIME charset > "iso-8859-8-i". It tried to find an Emacs coding system that had this > mime-charset property. But there wasn't any. So it gave up. If the attempt to find a coding-system by its MIME charset fails, I think VM should try using the string as the name of a coding-system. Would that work? > Note that (coding-system "iso-8859-8-i" :mime-charset) returns > "iso-8859-8". Right, because iso-8859-8-i is an alias. > What I am doing now is to see if there is a coding-system with the > same name as the mime-charset. I think you should do both, and try looking up MIME charset first. > When I don't find a coding-system with the given name, I am using > 'undecided, which is what I think you reocmmended. This at least gets > us out of the unibyte string problem, even though what is produced is > normally gibberish. That could be the last resort. > That is what I thought. But the OP is getting the "bad coding" text > even if a multibyte string is used as the buffer name. So, perhaps > there is a still problem there. Maybe. > The problem should show up if you do > > (generate-new-buffer "שולח דואר אלקטרוני") > > and switch to that buffer Emacs. At least on MS-Windows (which is what I have here), I see no problems. The text is displayed correctly and is legible. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-03 13:10 ` Eli Zaretskii @ 2011-01-03 21:07 ` Jan Djärv 0 siblings, 0 replies; 95+ messages in thread From: Jan Djärv @ 2011-01-03 21:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Uday S Reddy, user.emacs, emacs-devel Eli Zaretskii skrev 2011-01-03 14.10: >> (generate-new-buffer "שולח דואר אלקטרוני") This works fine on OSX also. emacs user skrev: > I am attaching a snapshot of the emacs frame. once I do > vm-discard-message-cache as uday suggested, the frame title is fine > now. (Uday, it seems that when I then exit vm and start it again, the > problem returns). I'm assuming it is some kind of caching thing. Jan D. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2011-01-02 20:43 ` Uday S Reddy 2011-01-02 22:06 ` Jan Djärv 2011-01-02 22:08 ` Eli Zaretskii @ 2011-01-03 0:27 ` Stefan Monnier 2 siblings, 0 replies; 95+ messages in thread From: Stefan Monnier @ 2011-01-03 0:27 UTC (permalink / raw) To: Uday S Reddy; +Cc: Eli Zaretskii, user.emacs, emacs-devel > I have now given up on using the mime-charset property to search for > coding systems because of the too many aliases going on. However, it IIUC the mime-charset property is rather meant for sending email, to figure out what name to use in the generated emails. Stefan ^ permalink raw reply [flat|nested] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 22:30 ` Jan Djärv ` (2 preceding siblings ...) 2011-01-01 12:00 ` Eli Zaretskii @ 2011-01-01 12:00 ` Eli Zaretskii 3 siblings, 0 replies; 95+ 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] 95+ 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 @ 2010-12-31 22:30 ` Jan Djärv 1 sibling, 0 replies; 95+ 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 13:19 ` Eli Zaretskii ` (2 preceding siblings ...) 2010-12-31 16:56 ` Stefan Monnier @ 2010-12-31 16:56 ` Stefan Monnier 3 siblings, 0 replies; 95+ 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 13:10 ` Jan Djärv 2010-12-31 13:19 ` Eli Zaretskii @ 2010-12-31 13:19 ` Eli Zaretskii 1 sibling, 0 replies; 95+ 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 12:53 ` Eli Zaretskii 2010-12-31 13:06 ` emacs user 2010-12-31 13:10 ` Jan Djärv @ 2010-12-31 13:10 ` Jan Djärv 2 siblings, 0 replies; 95+ 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 11:23 ` Jan Djärv 2010-12-31 11:26 ` emacs user 2010-12-31 12:53 ` Eli Zaretskii @ 2010-12-31 12:53 ` Eli Zaretskii 2 siblings, 0 replies; 95+ 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 10:49 ` Jan Djärv 2010-12-31 11:23 ` Jan Djärv @ 2010-12-31 11:23 ` Jan Djärv 2010-12-31 12:52 ` Eli Zaretskii 2010-12-31 12:52 ` Eli Zaretskii 3 siblings, 0 replies; 95+ 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 10:49 ` Jan Djärv 2010-12-31 11:23 ` Jan Djärv 2010-12-31 11:23 ` Jan Djärv @ 2010-12-31 12:52 ` Eli Zaretskii 2010-12-31 12:52 ` Eli Zaretskii 3 siblings, 0 replies; 95+ 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 10:49 ` Jan Djärv ` (2 preceding siblings ...) 2010-12-31 12:52 ` Eli Zaretskii @ 2010-12-31 12:52 ` Eli Zaretskii 2010-12-31 13:16 ` Eli Zaretskii 2010-12-31 13:16 ` Eli Zaretskii 3 siblings, 2 replies; 95+ messages in thread From: Eli Zaretskii @ 2010-12-31 12:52 UTC (permalink / raw) To: Jan Djärv; +Cc: cyd, 7517, user.emacs, emacs-devel > 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 12:52 ` Eli Zaretskii @ 2010-12-31 13:16 ` Eli Zaretskii 2010-12-31 13:16 ` Eli Zaretskii 1 sibling, 0 replies; 95+ 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] 95+ messages in thread
* Re: bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-31 12:52 ` Eli Zaretskii 2010-12-31 13:16 ` Eli Zaretskii @ 2010-12-31 13:16 ` Eli Zaretskii 1 sibling, 0 replies; 95+ 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] 95+ 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 @ 2010-12-30 11:35 ` Jan Djärv 1 sibling, 0 replies; 95+ 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] 95+ messages in thread
* bug#7517: 24.0.50; repeated crash under Mac OS X 2010-12-29 12:21 ` Jan Djärv 2010-12-29 15:41 ` Stefan Monnier @ 2010-12-29 15:41 ` Stefan Monnier 1 sibling, 0 replies; 95+ 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] 95+ 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 @ 2010-12-29 4:29 ` Chong Yidong 1 sibling, 0 replies; 95+ 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] 95+ messages in thread
end of thread, other threads:[~2011-01-03 21:34 UTC | newest] Thread overview: 95+ 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 2010-12-29 11:59 ` Jan Djärv 2010-12-29 11:59 ` Jan Djärv 2010-12-29 12:21 ` Jan Djärv 2010-12-29 12:21 ` Jan Djärv 2010-12-29 15:41 ` Stefan Monnier 2010-12-29 16:06 ` emacs user 2010-12-30 11:35 ` Jan Djärv 2010-12-30 14:20 ` emacs user 2010-12-30 22:02 ` Jan Djärv 2010-12-30 22:02 ` Jan Djärv 2010-12-31 6:11 ` emacs user 2010-12-31 6:12 ` emacs user 2010-12-31 8:18 ` Eli Zaretskii 2010-12-31 8:18 ` Eli Zaretskii 2010-12-31 11:16 ` emacs user 2010-12-31 10:49 ` Jan Djärv 2010-12-31 10:49 ` Jan Djärv 2010-12-31 11:23 ` Jan Djärv 2010-12-31 11:26 ` emacs user 2010-12-31 12:53 ` Eli Zaretskii 2010-12-31 13:06 ` emacs user 2010-12-31 13:18 ` Jan Djärv 2010-12-31 13:18 ` Jan Djärv 2010-12-31 13:10 ` Jan Djärv 2010-12-31 13:19 ` Eli Zaretskii 2010-12-31 14:22 ` Jan Djärv 2010-12-31 14:22 ` Jan Djärv 2010-12-31 16:07 ` Eli Zaretskii 2010-12-31 16:07 ` Eli Zaretskii 2010-12-31 16:09 ` emacs user 2010-12-31 16:09 ` emacs user 2010-12-31 18:57 ` Jan Djärv 2011-01-01 3:55 ` Stephen J. Turnbull 2011-01-01 3:55 ` Stephen J. Turnbull 2010-12-31 18:57 ` Jan Djärv 2010-12-31 16:56 ` Stefan Monnier 2010-12-31 17:42 ` emacs user 2010-12-31 22:30 ` Jan Djärv 2010-12-31 23:07 ` Stefan Monnier 2010-12-31 23:07 ` Stefan Monnier 2011-01-01 11:57 ` Eli Zaretskii 2011-01-01 12:46 ` emacs user 2011-01-01 12:46 ` emacs user 2011-01-01 15:40 ` Eli Zaretskii 2011-01-01 17:02 ` Uday S Reddy 2011-01-01 18:08 ` Eli Zaretskii 2011-01-01 18:08 ` Eli Zaretskii 2011-01-01 17:02 ` Uday S Reddy 2011-01-01 18:34 ` Jan D. 2011-01-02 14:02 ` Chong Yidong 2011-01-03 21:34 ` Jan Djärv 2011-01-03 21:34 ` Jan Djärv 2011-01-02 14:02 ` Chong Yidong 2011-01-01 15:40 ` Eli Zaretskii 2011-01-01 17:22 ` Stefan Monnier 2011-01-01 18:07 ` Eli Zaretskii 2011-01-01 18:07 ` Eli Zaretskii 2011-01-01 17:22 ` Stefan Monnier 2011-01-01 11:57 ` Eli Zaretskii 2011-01-01 12:00 ` Eli Zaretskii 2011-01-01 17:11 ` Stefan Monnier 2011-01-01 17:11 ` Stefan Monnier 2011-01-01 18:06 ` Eli Zaretskii 2011-01-01 18:06 ` Eli Zaretskii 2011-01-01 22:43 ` Uday S Reddy 2011-01-02 4:03 ` Eli Zaretskii 2011-01-02 20:43 ` Uday S Reddy 2011-01-02 22:06 ` Jan Djärv 2011-01-03 4:59 ` Uday S Reddy 2011-01-03 8:10 ` emacs user 2011-01-02 22:08 ` Eli Zaretskii 2011-01-03 4:50 ` Uday S Reddy 2011-01-03 13:10 ` Eli Zaretskii 2011-01-03 21:07 ` Jan Djärv 2011-01-03 0:27 ` Stefan Monnier 2011-01-01 12:00 ` Eli Zaretskii 2010-12-31 22:30 ` Jan Djärv 2010-12-31 16:56 ` Stefan Monnier 2010-12-31 13:19 ` Eli Zaretskii 2010-12-31 13:10 ` Jan Djärv 2010-12-31 12:53 ` Eli Zaretskii 2010-12-31 11:23 ` Jan Djärv 2010-12-31 12:52 ` Eli Zaretskii 2010-12-31 12:52 ` Eli Zaretskii 2010-12-31 13:16 ` Eli Zaretskii 2010-12-31 13:16 ` Eli Zaretskii 2010-12-30 11:35 ` Jan Djärv 2010-12-29 15:41 ` Stefan Monnier 2010-12-29 4:29 ` Chong Yidong
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.