Re: bug#7517: 24.0.50; repeated crash under Mac OS X

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Chong Yidong]

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?

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Jan Djärv]

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?

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Jan Djärv]

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.

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Stefan Monnier]

> 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

bug#7517: 24.0.50; repeated crash under Mac OS X

[emacs user]

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
>

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Jan Djärv]

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.

bug#7517: 24.0.50; repeated crash under Mac OS X

[emacs user]

[-- 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)  

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Jan Djärv]

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

bug#7517: 24.0.50; repeated crash under Mac OS X

[emacs user]

(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.
>>>
>

bug#7517: 24.0.50; repeated crash under Mac OS X

[emacs user]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Eli Zaretskii]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Jan Djärv]

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.

bug#7517: 24.0.50; repeated crash under Mac OS X

[emacs user]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Jan Djärv]

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.

bug#7517: 24.0.50; repeated crash under Mac OS X

[emacs user]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Eli Zaretskii]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Eli Zaretskii]

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

bug#7517: 24.0.50; repeated crash under Mac OS X

[emacs user]

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?

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Jan Djärv]

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.

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Eli Zaretskii]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Jan Djärv]

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?

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Eli Zaretskii]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Jan Djärv]

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.

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Eli Zaretskii]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[emacs user]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Stefan Monnier]

> 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

bug#7517: 24.0.50; repeated crash under Mac OS X

[emacs user]

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
>

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Jan Djärv]

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.

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Jan Djärv]

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.

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Stefan Monnier]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Stephen J. Turnbull]

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.

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Eli Zaretskii]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Eli Zaretskii]

> 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.)

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[emacs user]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Eli Zaretskii]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Uday S Reddy]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Stefan Monnier]

> 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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Stefan Monnier]

> 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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Eli Zaretskii]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Eli Zaretskii]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Eli Zaretskii]

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

bug#7517: 24.0.50; repeated crash under Mac OS X

[Jan D.]

Eli Zaretskii skrev 2011-01-01 16:40:

> right?
>
> I guess this bug report can be closed now.  Any objections?

No.

	Jan D.

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Uday S Reddy]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Eli Zaretskii]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Chong Yidong]

"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.

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Uday S Reddy]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Jan Djärv]

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.

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Eli Zaretskii]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Stefan Monnier]

> 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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Uday S Reddy]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Uday S Reddy]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[emacs user]

[-- 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 --]

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Eli Zaretskii]

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

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Jan Djärv]

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.

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

[Jan Djärv]

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.