Re: emacs crashed on windows-xp

Re: emacs crashed on windows-xp

[Jason Rumney]

[-- Attachment #1.1: Type: text/plain, Size: 929 bytes --]


>> It crashes with a message print out:
>>         Fatal error (11)Segmentation fault
>>
>> I'm running emacs-unicode-2 (CVS:2006-10-04) in Fedora core 5.
>>     
>
> Doesn't happen for me with CVS trunk on GNU/Linux (redhat 9.0).
>   

Strange, it does for me on GNU/Linux (Debian testing) as well as Windows..

Did you follow the exact formula Zhang Wei posted (across two different 
mails)?

    emacs -Q

    M-: (setq frame-title-format (list "%f (%l,%c) ---- @" system-name))

    C-h i m elisp <RET> m lists <RET> m rings <RET> u u


For me, the titlebar after the first u says (1, 2) with the cursor on line 21, column 2, where after the m lists it said (5091, 0) with the cursor on line 1, column 0 of the same manual page. Pressing C-l it says (21, 2), which is where the cursor is on the screen (as opposed to within the file, which I assume is where the 5091 came from), but pressing u again still causes a crash.



[-- Attachment #1.2: Type: text/html, Size: 1427 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: emacs crashed on windows-xp

[Jan Djärv]

Jason Rumney skrev:
> 
>>> It crashes with a message print out:
>>>         Fatal error (11)Segmentation fault
>>>
>>> I'm running emacs-unicode-2 (CVS:2006-10-04) in Fedora core 5.
>>>     
>>
>> Doesn't happen for me with CVS trunk on GNU/Linux (redhat 9.0).
>>   
> 
> Strange, it does for me on GNU/Linux (Debian testing) as well as Windows..


FWIW, it crashes for me with Mac OSX.

	Jan D.

Re: emacs crashed on many OSes (was: emacs crashed on windows-xp)

[Jan Djärv]

Jan Djärv skrev:
> 
> 
> Jason Rumney skrev:
>>
>>>> It crashes with a message print out:
>>>>         Fatal error (11)Segmentation fault
>>>>
>>>> I'm running emacs-unicode-2 (CVS:2006-10-04) in Fedora core 5.
>>>>     
>>>
>>> Doesn't happen for me with CVS trunk on GNU/Linux (redhat 9.0).
>>>   
>>
>> Strange, it does for me on GNU/Linux (Debian testing) as well as 
>> Windows..
> 
> 
> FWIW, it crashes for me with Mac OSX.
> 


And on FreeBSD 4.11.  Here is a backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x808cea3 in display_count_lines (start=219173, start_byte=219173,
     limit_byte=219583, count=217461, byte_pos_ptr=0xbfbfe710) at xdisp.c:18011
18011                   while (*cursor != '\n' && ++cursor != ceiling_addr)

(gdb) p cursor
$1 = (
     unsigned char *) 0x28635000 <Error reading address 0x28635000: Bad address>
(gdb) where
#0  0x808cea3 in display_count_lines (start=219173, start_byte=219173,
     limit_byte=219583, count=217461, byte_pos_ptr=0xbfbfe710) at xdisp.c:18011
#1  0x808c57d in decode_mode_spec (w=0x86afe00, c=108, field_width=0,
     precision=-3, multibyte=0xbfbfe7b4) at xdisp.c:17769
#2  0x808add6 in display_mode_element (it=0xbfbfe8b0, depth=2, field_width=0,
     precision=-1, elt=141645059, props=137934849, risky=0) at xdisp.c:16906
#3  0x808b274 in display_mode_element (it=0xbfbfe8b0, depth=1, field_width=-1,
     precision=-1, elt=138437181, props=137934849, risky=0) at xdisp.c:17101
#4  0x8078091 in x_consider_frame_title (frame=141225988) at xdisp.c:8994
#5  0x80781ec in prepare_menu_bars () at xdisp.c:9051
#6  0x807b82d in redisplay_internal (preserve_echo_area=0) at xdisp.c:10938
#7  0x807a8cc in redisplay () at xdisp.c:10519
#8  0x8124e79 in read_char (commandflag=1, nmaps=2, maps=0xbfbff538,
     prev_event=137934849, used_mouse_menu=0xbfbff5ec, end_time=0x0)
     at keyboard.c:2633
#9  0x812ea4f in read_key_sequence (keybuf=0xbfbff71c, bufsize=30,
     prompt=137934849, dont_downcase_last=0, can_return_switch_frame=1,
     fix_current_buffer=1) at keyboard.c:8963
#10 0x81226e5 in command_loop_1 () at keyboard.c:1603
#11 0x81a2bf5 in internal_condition_case (bfun=0x81223b4 <command_loop_1>,
     handlers=137999033, hfun=0x8121cf0 <cmd_error>) at eval.c:1481
#12 0x8122080 in command_loop_2 () at keyboard.c:1326
#13 0x81a2678 in internal_catch (tag=137993265,
     func=0x8122060 <command_loop_2>, arg=137934849) at eval.c:1222
#14 0x8122032 in command_loop () at keyboard.c:1305
#15 0x8121a47 in recursive_edit_1 () at keyboard.c:1003
#16 0x8121b97 in Frecursive_edit () at keyboard.c:1064
#17 0x81203e5 in main (argc=4, argv=0xbfbffa40) at emacs.c:1794

(gdb) p ceiling_addr
$2 = (
     unsigned char *) 0x285f7ae5 "\037\nFile: elisp,  Node: Introduction, 
Next: Lisp Data Types,  Prev: Top,  Up: Top\n\n1 Introduction\n", '*' <repeats 
14 times>, "\n\nMost of the GNU Emacs text editor is written in the 
programming\nlanguage called Emacs L"...
(gdb) p cursor
$3 = (
     unsigned char *) 0x28635000 <Error reading address 0x28635000: Bad address>
(gdb) p base
$4 = (
     unsigned char *) 0x2862083c "File: elisp,  Node: Lists,  Next: Sequences 
Arrays Vectors,  Prev: Strings and Characters,  Up: Top\n\n5 
Lists\n*******\n\nA \"list\" represents a sequence of zero or more elements 
(which may be\nany Lisp obj"...
(gdb) p start_byte
$5 = 219173
(gdb) p limit_byte
$6 = 219583
(gdb) p ceiling
$7 = 51917


I'll leave it running in gdb.  If anybody can figure this out or need more 
debugging done,  just let me know.

	Jan D.

Re: emacs crashed on windows-xp

[Kim F. Storm]

Jason Rumney <jasonr@gnu.org> writes:

> Did you follow the exact formula Zhang Wei posted (across two
> different mails)?

Sorry no.  With the procedure below, it crashes for me too (GNU/Linux).

>
>    emacs -Q
>
>    M-: (setq frame-title-format (list "%f (%l,%c) ---- @" system-name))
>
>    C-h i m elisp <RET> m lists <RET> m rings <RET> u u

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: emacs crashed on windows-xp

[Kim F. Storm]

Jason Rumney <jasonr@gnu.org> writes:

>>> It crashes with a message print out:
>>>         Fatal error (11)Segmentation fault
>>>
>>> I'm running emacs-unicode-2 (CVS:2006-10-04) in Fedora core 5.
>>>     
>>
>> Doesn't happen for me with CVS trunk on GNU/Linux (redhat 9.0).
>>   
>
> Strange, it does for me on GNU/Linux (Debian testing) as well as Windows..
>
> Did you follow the exact formula Zhang Wei posted (across two
> different mails)?
>
>    emacs -Q
>
>    M-: (setq frame-title-format (list "%f (%l,%c) ---- @" system-name))
>
>    C-h i m elisp <RET> m lists <RET> m rings <RET> u u


I looked briefly at this (don't have time to dig further right now).

It seems that the problem is that in redisplay_internal, the frame title is
drawn _before_ the windows are updated, so the stuff which depends on 
actual window contents (such as %l) may fail to render properly -- and
even crash emacs as we have seen here.

Perhaps a simple fix would be to move the call to x_consider_frame_title
currently inside prepare_menu_bars to after we have completed the
window updates...

Unfortunately, this comment says this is not TRT ... so what is TRT?

  /* Update all frame titles based on their buffer names, etc.  We do
     this before the menu bars so that the buffer-menu will show the
     up-to-date frame titles.  */

BTW, what does frame titles have to do with the buffer menu?


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: emacs crashed on windows-xp

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: Thu, 12 Oct 2006 16:04:57 +0200
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
>   /* Update all frame titles based on their buffer names, etc.  We do
>      this before the menu bars so that the buffer-menu will show the
>      up-to-date frame titles.  */
> 
> BTW, what does frame titles have to do with the buffer menu?

Perhaps this comment refers to the fact that Buffers->Frames menu-bar
menu shows a name for each frame, and that name is taken from the
titles of the frames?

Re: emacs crashed on windows-xp

[Stefan Monnier]

> It seems that the problem is that in redisplay_internal, the frame title is
> drawn _before_ the windows are updated, so the stuff which depends on 
> actual window contents (such as %l) may fail to render properly -- and
> even crash emacs as we have seen here.

> Perhaps a simple fix would be to move the call to x_consider_frame_title
> currently inside prepare_menu_bars to after we have completed the
> window updates...

> Unfortunately, this comment says this is not TRT ... so what is TRT?

>   /* Update all frame titles based on their buffer names, etc.  We do
>      this before the menu bars so that the buffer-menu will show the
>      up-to-date frame titles.  */

But the menubar is supposedly "closed" at this point, so unless one of the
menu titles refers to the frame name, it shouldn't make a difference, right?


        Stefan

Re: emacs crashed on many OSes (was: emacs crashed on windows-xp)

[Giorgos Keramidas]

[-- Attachment #1.1: Type: text/plain, Size: 1982 bytes --]

On 2006-10-12 08:52, Jan Dj?rv <jan.h.d@swipnet.se> wrote:
> 
> 
> Jan Dj?rv skrev:
> >
> >
> >Jason Rumney skrev:
> >>
> >>>>It crashes with a message print out:
> >>>>        Fatal error (11)Segmentation fault
> >>>>
> >>>>I'm running emacs-unicode-2 (CVS:2006-10-04) in Fedora core 5.
> >>>>    
> >>>
> >>>Doesn't happen for me with CVS trunk on GNU/Linux (redhat 9.0).
> >>>  
> >>
> >>Strange, it does for me on GNU/Linux (Debian testing) as well as 
> >>Windows..
> >
> >
> >FWIW, it crashes for me with Mac OSX.
> >
> 
> 
> And on FreeBSD 4.11.  Here is a backtrace:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x808cea3 in display_count_lines (start=219173, start_byte=219173,
>     limit_byte=219583, count=217461, byte_pos_ptr=0xbfbfe710) at 
>     xdisp.c:18011
> 18011                   while (*cursor != '\n' && ++cursor != ceiling_addr)
> (gdb) p cursor
> $1 = (
>     unsigned char *) 0x28635000 <Error reading address 0x28635000: Bad 
>     address>
> (gdb) where
> #0  0x808cea3 in display_count_lines (start=219173, start_byte=219173,
>     limit_byte=219583, count=217461, byte_pos_ptr=0xbfbfe710) at 
>     xdisp.c:18011
> #1  0x808c57d in decode_mode_spec (w=0x86afe00, c=108, field_width=0,
>     precision=-3, multibyte=0xbfbfe7b4) at xdisp.c:17769
> #2  0x808add6 in display_mode_element (it=0xbfbfe8b0, depth=2, 
> field_width=0,
>     precision=-1, elt=141645059, props=137934849, risky=0) at xdisp.c:16906
> #3  0x808b274 in display_mode_element (it=0xbfbfe8b0, depth=1, 
> field_width=-1,
>     precision=-1, elt=138437181, props=137934849, risky=0) at xdisp.c:17101

Hi Jan,

Is this a recent CVS snapshot or a build of the editors/emacs-devel port?

I'm in the middle of the process of updating the port with a snapshot
after the latest leim/ Makefile fixes by Kenichi-san, so if you are
using the FreeBSD port I'd be interested to know if you can test the new
version too :)


[-- Attachment #1.2: Type: application/pgp-signature, Size: 187 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: emacs crashed on many OSes

[Jan D.]

Giorgos Keramidas skrev:
> On 2006-10-12 08:52, Jan Dj?rv <jan.h.d@swipnet.se> wrote:
>   
>> And on FreeBSD 4.11.  Here is a backtrace:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x808cea3 in display_count_lines (start=219173, start_byte=219173,
>>     limit_byte=219583, count=217461, byte_pos_ptr=0xbfbfe710) at 
>>     xdisp.c:18011
>> 18011                   while (*cursor != '\n' && ++cursor != ceiling_addr)
>> (gdb) p cursor
>> $1 = (
>>     unsigned char *) 0x28635000 <Error reading address 0x28635000: Bad 
>>     address>
>> (gdb) where
>> #0  0x808cea3 in display_count_lines (start=219173, start_byte=219173,
>>     limit_byte=219583, count=217461, byte_pos_ptr=0xbfbfe710) at 
>>     xdisp.c:18011
>>
>>     
> Hi Jan,
>
> Is this a recent CVS snapshot or a build of the editors/emacs-devel port?
>   

A recent CVS.

> I'm in the middle of the process of updating the port with a snapshot
> after the latest leim/ Makefile fixes by Kenichi-san, so if you are
> using the FreeBSD port I'd be interested to know if you can test the new
> version too :)

Sorry, it is not my machine, I only have limited access to it.  If you
can mail me the port as a tar,  I can test it.

    Jan D.

Re: emacs crashed on windows-xp

[Richard Stallman]

    It seems that the problem is that in redisplay_internal, the frame title is
    drawn _before_ the windows are updated, so the stuff which depends on 
    actual window contents (such as %l) may fail to render properly -- and
    even crash emacs as we have seen here.

Making the frame title depend on the way the window was displayed is a
somewhat strange thing to do.

    Perhaps a simple fix would be to move the call to x_consider_frame_title
    currently inside prepare_menu_bars to after we have completed the
    window updates...

That would be risky for various reasons (including the one in the
comment).

I think it might be best to disable the use of %l and %c in frame
titles.

Re: emacs crashed on many OSes

[Giorgos Keramidas]

On 2006-10-12 21:12, "Jan D." <jan.h.d@swipnet.se> wrote:
>Giorgos Keramidas skrev:
>>> (gdb) where
>>> #0  0x808cea3 in display_count_lines (start=219173, start_byte=219173,
>>>     limit_byte=219583, count=217461, byte_pos_ptr=0xbfbfe710) at 
>>>     xdisp.c:18011
>>     
>> Hi Jan,
>>
>> Is this a recent CVS snapshot or a build of the editors/emacs-devel port?
> 
> A recent CVS.

:-)
 
>> I'm in the middle of the process of updating the port with a snapshot
>> after the latest leim/ Makefile fixes by Kenichi-san, so if you are
>> using the FreeBSD port I'd be interested to know if you can test the
>> new version too :)
> 
> Sorry, it is not my machine, I only have limited access to it.  If you
> can mail me the port as a tar, I can test it.

I will.  Thanks for volunteering to test it.  I don't have 4.X systems
around, and having it tested on as many FreeBSD versions as possible is
going to be nice!

Re: emacs crashed on windows-xp

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     It seems that the problem is that in redisplay_internal, the frame title is
>     drawn _before_ the windows are updated, so the stuff which depends on 
>     actual window contents (such as %l) may fail to render properly -- and
>     even crash emacs as we have seen here.
>
> Making the frame title depend on the way the window was displayed is a
> somewhat strange thing to do.
>
>     Perhaps a simple fix would be to move the call to x_consider_frame_title
>     currently inside prepare_menu_bars to after we have completed the
>     window updates...
>
> That would be risky for various reasons (including the one in the
> comment).
>
> I think it might be best to disable the use of %l and %c in frame
> titles.

That may indeed be the simplest approach -- as the information may not
be up-to-date anyway...  Also, the frame-title isn't updated for every
redisplay, and doing so would be silly just for this purpose.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: emacs crashed on windows-xp

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> Making the frame title depend on the way the window was displayed is a
> somewhat strange thing to do.
>
> I think it might be best to disable the use of %l and %c in frame
> titles.

How about this patch?  I can update the Lisp reference manual too.

*** emacs/src/xdisp.c.~1.1124.~	2006-10-07 12:11:06.000000000 -0400
--- emacs/src/xdisp.c	2006-10-12 22:47:25.000000000 -0400
***************
*** 17680,17691 ****
        break;
  
      case 'c':
!       {
! 	int col = (int) current_column (); /* iftc */
! 	w->column_number_displayed = make_number (col);
! 	pint2str (decode_mode_spec_buf, field_width, col);
! 	return decode_mode_spec_buf;
!       }
  
      case 'e':
  #ifndef SYSTEM_MALLOC
--- 17680,17699 ----
        break;
  
      case 'c':
!       /* %c and %l are ignored in `frame-title-format'.
!          (In redisplay_internal, the frame title is drawn _before_ the
!          windows are updated, so the stuff which depends on actual
!          window contents (such as %l) may fail to render properly, or
!          even crash emacs.)  */
!       if (mode_line_target == MODE_LINE_TITLE)
! 	return "";
!       else
! 	{
! 	  int col = (int) current_column (); /* iftc */
! 	  w->column_number_displayed = make_number (col);
! 	  pint2str (decode_mode_spec_buf, field_width, col);
! 	  return decode_mode_spec_buf;
! 	}
  
      case 'e':
  #ifndef SYSTEM_MALLOC
***************
*** 17727,17737 ****
  
      case 'l':
        {
! 	int startpos = XMARKER (w->start)->charpos;
! 	int startpos_byte = marker_byte_position (w->start);
! 	int line, linepos, linepos_byte, topline;
! 	int nlines, junk;
! 	int height = WINDOW_TOTAL_LINES (w);
  
  	/* If we decided that this buffer isn't suitable for line numbers,
  	   don't forget that too fast.  */
--- 17735,17750 ----
  
      case 'l':
        {
! 	int startpos, startpos_byte, line, linepos, linepos_byte;
! 	int topline, nlines, junk, height;
! 
! 	/* %c and %l are ignored in `frame-title-format'.  */
! 	if (mode_line_target == MODE_LINE_TITLE)
! 	  return "";
! 
! 	startpos = XMARKER (w->start)->charpos;
! 	startpos_byte = marker_byte_position (w->start);
! 	height = WINDOW_TOTAL_LINES (w);
  
  	/* If we decided that this buffer isn't suitable for line numbers,
  	   don't forget that too fast.  */
***************
*** 23986,23994 ****
    DEFVAR_LISP ("frame-title-format", &Vframe_title_format,
      doc: /* Template for displaying the title bar of visible frames.
  \(Assuming the window manager supports this feature.)
! This variable has the same structure as `mode-line-format' (which see),
! and is used only on frames for which no explicit name has been set
! \(see `modify-frame-parameters').  */);
  
    DEFVAR_LISP ("icon-title-format", &Vicon_title_format,
      doc: /* Template for displaying the title bar of an iconified frame.
--- 23999,24008 ----
    DEFVAR_LISP ("frame-title-format", &Vframe_title_format,
      doc: /* Template for displaying the title bar of visible frames.
  \(Assuming the window manager supports this feature.)
! 
! This variable has the same structure as `mode-line-format', except that
! the %c and %l constructs are ignored.  It is used only on frames for
! which no explicit name has been set \(see `modify-frame-parameters').  */);
  
    DEFVAR_LISP ("icon-title-format", &Vicon_title_format,
      doc: /* Template for displaying the title bar of an iconified frame.

Re: emacs crashed on windows-xp

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> Making the frame title depend on the way the window was displayed is a
>> somewhat strange thing to do.
>>
>> I think it might be best to disable the use of %l and %c in frame
>> titles.
>
> How about this patch?  I can update the Lisp reference manual too.
>
> *** emacs/src/xdisp.c.~1.1124.~	2006-10-07 12:11:06.000000000 -0400
> --- emacs/src/xdisp.c	2006-10-12 22:47:25.000000000 -0400

Looks good!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: emacs crashed on windows-xp

[Jason Rumney]

Chong Yidong wrote:
>       case 'c':
> !       /* %c and %l are ignored in `frame-title-format'.
> !          (In redisplay_internal, the frame title is drawn _before_ the
> !          windows are updated, so the stuff which depends on actual
> !          window contents (such as %l) may fail to render properly, or
> !          even crash emacs.)  */
> !       if (mode_line_target == MODE_LINE_TITLE)
> ! 	return "";
>   
...
>       case 'l':
>         {
> ! 	int startpos, startpos_byte, line, linepos, linepos_byte;
> ! 	int topline, nlines, junk, height;
> ! 
> ! 	/* %c and %l are ignored in `frame-title-format'.  */
> ! 	if (mode_line_target == MODE_LINE_TITLE)
> ! 	  return "";
>   

I think it would be better to return "%c" and "%l", then it will be more 
obvious to users that those format specifiers are not handled in the 
title-bar. Returning a blank string makes it look like those specifiers 
were handled in some way, and may lead to bug reports.

Re: emacs crashed on windows-xp

[Richard Stallman]

    That may indeed be the simplest approach -- as the information may not
    be up-to-date anyway...  Also, the frame-title isn't updated for every
    redisplay, and doing so would be silly just for this purpose.

Could you do that?

I don't want to try to make this usage work, not now,
because changes there are likely to break things.

Re: emacs crashed on windows-xp

[Richard Stallman]

Please install your patch, and please do update the Lisp manual.

Re: emacs crashed on windows-xp

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> Please install your patch, and please do update the Lisp manual.

Done.  I added a note to NEWS too.

Re: emacs crashed on windows-xp

[Eli Zaretskii]

> Date: Fri, 13 Oct 2006 12:01:00 +0100
> From: Jason Rumney <jasonr@gnu.org>
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> I think it would be better to return "%c" and "%l"

Either that, or produce a warning message about the non-support
(although displaying messages is somewhat tricky during redisplay).

> Returning a blank string makes it look like those specifiers were
> handled in some way, and may lead to bug reports.

100% agreement.

Re: emacs crashed on windows-xp

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 13 Oct 2006 12:01:00 +0100
>> From: Jason Rumney <jasonr@gnu.org>
>> Cc: Emacs Devel <emacs-devel@gnu.org>
>> 
>> I think it would be better to return "%c" and "%l"
>
> Either that, or produce a warning message about the non-support
> (although displaying messages is somewhat tricky during redisplay).
>
>> Returning a blank string makes it look like those specifiers were
>> handled in some way, and may lead to bug reports.
>
> 100% agreement.

Returning a blank string is what we currently do for invalid %
constructs, like %u or whatever.

Re: emacs crashed on windows-xp

[Eli Zaretskii]

> Cc: Jason Rumney <jasonr@gnu.org>,  emacs-devel@gnu.org
> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Fri, 13 Oct 2006 12:56:32 -0400
> 
> >> Returning a blank string makes it look like those specifiers were
> >> handled in some way, and may lead to bug reports.
> >
> > 100% agreement.
> 
> Returning a blank string is what we currently do for invalid %
> constructs, like %u or whatever.

But %l and %c are not invalid % constructs.