all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* 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

* 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

* 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

* 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  4:29       ` Chong Yidong
  2010-12-29 11:59         ` Jan Djärv
  2010-12-29 11:59         ` Jan Djärv
  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 12:21           ` Jan Djärv
  2010-12-29 12:21           ` Jan Djärv
  2010-12-29 11:59         ` 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

* 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

* 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

* 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

* 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
  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: 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 11:16                           ` emacs user
  2010-12-31  8:18                         ` Eli Zaretskii
                                           ` (2 subsequent siblings)
  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  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

* 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 10:49                         ` Jan Djärv
@ 2010-12-31 11:23                           ` Jan Djärv
  2010-12-31 11:23                           ` Jan Djärv
                                             ` (2 subsequent siblings)
  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

* 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:23                           ` Jan Djärv
  2010-12-31 11:26                             ` emacs user
                                               ` (2 more replies)
  2010-12-31 12:52                           ` Eli Zaretskii
  2010-12-31 12:52                           ` Eli Zaretskii
  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

* 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
  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
  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 13:16                             ` Eli Zaretskii
  2010-12-31 13:16                             ` Eli Zaretskii
  2010-12-31 12:52                           ` 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 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

* 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

* 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

* 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

* 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-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 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: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

* 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:09                                       ` emacs user
                                                         ` (3 more replies)
  2010-12-31 16:07                                     ` Eli Zaretskii
  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

* 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
                                                         ` (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 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 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

* Re: 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
  2010-12-31 17:42                                     ` emacs user
  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

* 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: 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 16:07                                     ` Eli Zaretskii
                                                         ` (2 preceding siblings ...)
  2010-12-31 18:57                                       ` Jan Djärv
@ 2010-12-31 18:57                                       ` Jan Djärv
  2011-01-01  3:55                                         ` Stephen J. Turnbull
  2011-01-01  3:55                                         ` Stephen J. Turnbull
  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 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

* 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 22:30                                       ` Jan Djärv
  2010-12-31 23:07                                         ` Stefan Monnier
                                                           ` (3 more replies)
  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
  2011-01-01 12:00                                         ` Eli Zaretskii
  2011-01-01 12:00                                         ` Eli Zaretskii
  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
  2011-01-01 11:57                                           ` Eli Zaretskii
  2011-01-01 11:57                                           ` Eli Zaretskii
  2010-12-31 23:07                                         ` Stefan Monnier
                                                           ` (2 subsequent siblings)
  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

* 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 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 23:07                                         ` Stefan Monnier
  2011-01-01 11:57                                           ` Eli Zaretskii
@ 2011-01-01 11:57                                           ` Eli Zaretskii
  2011-01-01 12:46                                             ` emacs user
                                                               ` (3 more replies)
  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
  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 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

* Re: 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
  2011-01-01 17:11                                           ` Stefan Monnier
  2011-01-01 17:11                                           ` Stefan Monnier
  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 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

* 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 12:46                                             ` emacs user
  2011-01-01 15:40                                               ` Eli Zaretskii
@ 2011-01-01 15:40                                               ` Eli Zaretskii
  2011-01-01 17:02                                                 ` Uday S Reddy
                                                                   ` (2 more replies)
  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

* 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

* 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 17:02                                                 ` Uday S Reddy
  2011-01-01 18:08                                                   ` Eli Zaretskii
  2011-01-01 18:08                                                   ` Eli Zaretskii
  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 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 18:06                                             ` Eli Zaretskii
  2011-01-01 18:06                                             ` Eli Zaretskii
  2011-01-01 17:11                                           ` Stefan Monnier
  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

* 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

* 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

* 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 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: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

* 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: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.
  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: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

* 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

* 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-02 14:02                                                   ` Chong Yidong
  2011-01-03 21:34                                                     ` Jan Djärv
  2011-01-03 21:34                                                     ` Jan Djärv
  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

* 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 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 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

* 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-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-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

* 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

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  4:29       ` Chong Yidong
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 11:16                           ` emacs user
2010-12-31  8:18                         ` Eli Zaretskii
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: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: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
2011-01-01  3:55                                         ` Stephen J. Turnbull
2011-01-01  3:55                                         ` Stephen J. Turnbull
2010-12-31 16:07                                     ` Eli Zaretskii
2010-12-31 16:56                                   ` Stefan Monnier
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
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: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:02                                                 ` Uday S Reddy
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 18:34                                                 ` Jan D.
2011-01-02 14:02                                                   ` Chong Yidong
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-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
2010-12-31 23:07                                         ` Stefan Monnier
2011-01-01 12:00                                         ` Eli Zaretskii
2011-01-01 12:00                                         ` Eli Zaretskii
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 17:11                                           ` 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 12:52                           ` Eli Zaretskii
2010-12-31 13:16                             ` Eli Zaretskii
2010-12-31 13:16                             ` Eli Zaretskii
2010-12-31 12:52                           ` Eli Zaretskii
2010-12-30 11:35                 ` Jan Djärv
2010-12-29 15:41             ` Stefan Monnier
2010-12-29 11:59         ` Jan Djärv

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.