xdisp.c problem?

xdisp.c problem?

[Tak Ota]

2003-01-29  Kenichi Handa  <handa@m17n.org>

	* xdisp.c (set_cursor_from_row): Pay attention to string display
	properties.

This change causes emacs to get hung when I try to view a message of
the following type.  Switching back to the old xdisp.c eliminates the
problem.

Content-Type: text/html; charset="euc-kr"

I am using BDF font on the following system.

In GNU Emacs 21.3.50.1 (i386-msvc-nt5.0.2195)
 of 2003-01-29 on TAK_4100
configured using `configure --with-msvc (12.00)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Re: xdisp.c problem?

[Kenichi Handa]

In article <20030129.153321.35784511.Takaaki.Ota@am.sony.com>, Tak Ota <Takaaki.Ota@am.sony.com> writes:

> 2003-01-29  Kenichi Handa  <handa@m17n.org>
> 	* xdisp.c (set_cursor_from_row): Pay attention to string display
> 	properties.

> This change causes emacs to get hung when I try to view a message of
> the following type.  Switching back to the old xdisp.c eliminates the
> problem.

> Content-Type: text/html; charset="euc-kr"

Could you show me exactly what to do to reproduce that bug?

---
Ken'ichi HANDA
handa@m17n.org

Re: xdisp.c problem?

[Tak Ota]

Thu, 30 Jan 2003 09:00:39 +0900 (JST): Kenichi Handa <handa@m17n.org> wrote:

> In article <20030129.153321.35784511.Takaaki.Ota@am.sony.com>, Tak Ota <Takaaki.Ota@am.sony.com> writes:
> 
> > 2003-01-29  Kenichi Handa  <handa@m17n.org>
> > 	* xdisp.c (set_cursor_from_row): Pay attention to string display
> > 	properties.
> 
> > This change causes emacs to get hung when I try to view a message of
> > the following type.  Switching back to the old xdisp.c eliminates the
> > problem.
> 
> > Content-Type: text/html; charset="euc-kr"
> 
> Could you show me exactly what to do to reproduce that bug?

I tried to isolate the case from the entire circumstance, which is
using Mew package to view email messages.  I was not successful.  It
happens only when I try to view certain messages.  C-g does not break
emacs once it gets trapped in this situation.  There is one more fact
I have gained by tracing elisp execution.  The last lisp function
called is `overlay-put' and the emacs stops responding after that.  I
used C debugger to follow the trace from entry to `overlay-put' but
could not conclusion anything meaningful.

I'm sorry but I don't know how to let you experience this.

-Tak

Re: xdisp.c problem?

[Kenichi Handa]

In article <20030129.174125.01368882.Takaaki.Ota@am.sony.com>, Tak Ota <Takaaki.Ota@am.sony.com> writes:
>>  > 2003-01-29  Kenichi Handa  <handa@m17n.org>
>>  > 	* xdisp.c (set_cursor_from_row): Pay attention to string display
>>  > 	properties.
>>  
>>  > This change causes emacs to get hung when I try to view a message of
>>  > the following type.  Switching back to the old xdisp.c eliminates the
>>  > problem.
>>  
>>  > Content-Type: text/html; charset="euc-kr"
>>  
>>  Could you show me exactly what to do to reproduce that bug?

> I tried to isolate the case from the entire circumstance, which is
> using Mew package to view email messages.  I was not successful.  It
> happens only when I try to view certain messages.  C-g does not break
> emacs once it gets trapped in this situation.  There is one more fact
> I have gained by tracing elisp execution.  The last lisp function
> called is `overlay-put' and the emacs stops responding after that.  I
> used C debugger to follow the trace from entry to `overlay-put' but
> could not conclusion anything meaningful.

Please check if Emacs is in an infinite loop or not, and if
it's in an infinite loop, find in which part of code it's
executing.

It's not likely that the modified function
set_cursor_from_row itself has an infinite loop, but it may
set cursor position to where the other display engine code
don't expect.

---
Ken'ichi HANDA
handa@m17n.org

Re: xdisp.c problem?

[Masatake YAMATO]

> I tried to isolate the case from the entire circumstance, which is
> using Mew package to view email messages.  I was not successful.  It
> happens only when I try to view certain messages. 

My emacs gets hung, too when I moves the point to "[End of message]"
of mew buffer. I'm using GNU/Linux. The echo area and header line are
flushed repeatedly.

> C-g does not break emacs once it gets trapped in this situation.
C-g doesn't work, too. However, mouse click on emacs buffer works.
So I don't have to kill emacs from a terminal. I can continue to 
use a emacs process after hunging.

Is this message any hit for fix the bug?
Masatake YAMATO

Re: xdisp.c problem?

[Tak Ota]

Thu, 30 Jan 2003 12:51:03 +0900 (JST): Kenichi Handa <handa@m17n.org> wrote:

> In article <20030129.174125.01368882.Takaaki.Ota@am.sony.com>, Tak Ota <Takaaki.Ota@am.sony.com> writes:
> >>  > 2003-01-29  Kenichi Handa  <handa@m17n.org>
> >>  > 	* xdisp.c (set_cursor_from_row): Pay attention to string display
> >>  > 	properties.
> >>  
> >>  > This change causes emacs to get hung when I try to view a message of
> >>  > the following type.  Switching back to the old xdisp.c eliminates the
> >>  > problem.
> >>  
> >>  > Content-Type: text/html; charset="euc-kr"
> >>  
> >>  Could you show me exactly what to do to reproduce that bug?
> 
> > I tried to isolate the case from the entire circumstance, which is
> > using Mew package to view email messages.  I was not successful.  It
> > happens only when I try to view certain messages.  C-g does not break
> > emacs once it gets trapped in this situation.  There is one more fact
> > I have gained by tracing elisp execution.  The last lisp function
> > called is `overlay-put' and the emacs stops responding after that.  I
> > used C debugger to follow the trace from entry to `overlay-put' but
> > could not conclusion anything meaningful.
> 
> Please check if Emacs is in an infinite loop or not, and if
> it's in an infinite loop, find in which part of code it's
> executing.

I'll try it later.  While I played with the problem a bit more
yesterday I narrowed it to the following action.

(overlay-put
 (make-overlay (point-max) (point-max))
 'before-string
 "[End of message]")

The difficulty to reproduce this for you is that it is buffer content
dependent.  If I save the buffer to a file the text properties are
gone.  I don't know if text properties are relevant to this problem
but saving the buffer to a file and revisiting it and performing above
action does not produce the problem anymore.  Is there a way to save
the complete buffer information to a file including text properties?

> It's not likely that the modified function
> set_cursor_from_row itself has an infinite loop, but it may
> set cursor position to where the other display engine code
> don't expect.

I agree with your insight.

-Tak

Re: xdisp.c problem?

[Tak Ota]

Thu, 30 Jan 2003 12:51:03 +0900 (JST): Kenichi Handa <handa@m17n.org> wrote:

> In article <20030129.174125.01368882.Takaaki.Ota@am.sony.com>, Tak Ota <Takaaki.Ota@am.sony.com> writes:
> >>  > 2003-01-29  Kenichi Handa  <handa@m17n.org>
> >>  > 	* xdisp.c (set_cursor_from_row): Pay attention to string display
> >>  > 	properties.
> >>  
> >>  > This change causes emacs to get hung when I try to view a message of
> >>  > the following type.  Switching back to the old xdisp.c eliminates the
> >>  > problem.
> >>  
> >>  > Content-Type: text/html; charset="euc-kr"
> >>  
> >>  Could you show me exactly what to do to reproduce that bug?
> 
> > I tried to isolate the case from the entire circumstance, which is
> > using Mew package to view email messages.  I was not successful.  It
> > happens only when I try to view certain messages.  C-g does not break
> > emacs once it gets trapped in this situation.  There is one more fact
> > I have gained by tracing elisp execution.  The last lisp function
> > called is `overlay-put' and the emacs stops responding after that.  I
> > used C debugger to follow the trace from entry to `overlay-put' but
> > could not conclusion anything meaningful.
> 
> Please check if Emacs is in an infinite loop or not, and if
> it's in an infinite loop, find in which part of code it's
> executing.

Yes, Emacs is looping infinitely.  It is spinning busily inside
command_loop_2 which calls internal_condition_case which calls
command_loop_1 which calls read_key_sequence.  Somewhere down in
read_key_sequence is thrown an exception.  The longjump lands back in
setjmp in the internal_condition_case which returns to
command_loop_2.  This repeats forever.

I tried to find what exception it is and from where in the downstream
of read_key_sequence it is thrown, then I ran out of my time for now.
I'll continue the pursuit later.

-Tak

Re: xdisp.c problem?

[Tak Ota]

Thu, 30 Jan 2003 13:13:22 -0800 (PST): Tak Ota <Takaaki.Ota@am.sony.com> wrote:

> Thu, 30 Jan 2003 12:51:03 +0900 (JST): Kenichi Handa <handa@m17n.org> wrote:
> 
> > In article <20030129.174125.01368882.Takaaki.Ota@am.sony.com>, Tak Ota <Takaaki.Ota@am.sony.com> writes:
> > >>  > 2003-01-29  Kenichi Handa  <handa@m17n.org>
> > >>  > 	* xdisp.c (set_cursor_from_row): Pay attention to string display
> > >>  > 	properties.
> > >>  
> > >>  > This change causes emacs to get hung when I try to view a message of
> > >>  > the following type.  Switching back to the old xdisp.c eliminates the
> > >>  > problem.
> > >>  
> > >>  > Content-Type: text/html; charset="euc-kr"
> > >>  
> > >>  Could you show me exactly what to do to reproduce that bug?
> > 
> > > I tried to isolate the case from the entire circumstance, which is
> > > using Mew package to view email messages.  I was not successful.  It
> > > happens only when I try to view certain messages.  C-g does not break
> > > emacs once it gets trapped in this situation.  There is one more fact
> > > I have gained by tracing elisp execution.  The last lisp function
> > > called is `overlay-put' and the emacs stops responding after that.  I
> > > used C debugger to follow the trace from entry to `overlay-put' but
> > > could not conclusion anything meaningful.
> > 
> > Please check if Emacs is in an infinite loop or not, and if
> > it's in an infinite loop, find in which part of code it's
> > executing.
> 
> Yes, Emacs is looping infinitely.  It is spinning busily inside
> command_loop_2 which calls internal_condition_case which calls
> command_loop_1 which calls read_key_sequence.  Somewhere down in
> read_key_sequence is thrown an exception.  The longjump lands back in
> setjmp in the internal_condition_case which returns to
> command_loop_2.  This repeats forever.
> 
> I tried to find what exception it is and from where in the downstream
> of read_key_sequence it is thrown, then I ran out of my time for now.
> I'll continue the pursuit later.

Here is the complete trace to where unwind_to_catch brings us back to
internal_condition_case and the descending starts all over again.  The
function set_cursor_from_row is in the trace.  It was not a simple
loop but continuous signal generation caused by the change to
internal_condition_case.

Since I'm not familiar with your change I'll simply keep the debugger
as is for a while.  Let me know if you want to examine values of
specific variables.

-Tak

unwind_to_catch() line 1172
Fsignal(int 0x112b125c, int 0x519a46dc) line 1547 + 12 bytes
args_out_of_range(int 0x00000000, int 0x00000000) line 140 + 35 bytes
validate_interval_range(int 0x41942000, int * 0x0082f024, int * 0x0082f024, int 0x00000000) line 151 + 8 bytes
Ftext_properties_at(int 0x00000000, int 0x41942000) line 585 + 16 bytes
get_char_property_and_overlay(int 0x00000000, int 0x112d38ac, int 0x0082f030, int * 0x00000000) line 688 + 12 bytes
Fnext_single_char_property_change(int 0x00000000, int 0x112d38ac, int 0x11297404, int 0x000006f5) line 802
set_cursor_from_row(window * 0x019f9400, glyph_row * 0x00000000, glyph_matrix * 0x01a85000, int 0x00000000, int 0x00000000, int 0x00000000, int 0x00000000) line 9527 + 24 bytes
display_line(it * 0x01b0cc3c) line 13577 + 22 bytes
try_window(int 0x419f9400, text_pos {...}) line 10978 + 12 bytes
redisplay_window(int 0x419f9400, int 0x00000000) line 10617 + 10 bytes
redisplay_window_0(int 0x419f9400) line 9437 + 10 bytes
internal_condition_case_1(int (void)* 0x01046997 redisplay_window_0(int), int 0x419f9400, int 0x512c4654, int (void)* 0x01046980 redisplay_window_error(void)) line 1392 + 53 bytes
redisplay_windows(int 0x4154a400) line 9418 + 29 bytes
redisplay_windows(int 0x419f9000) line 9408 + 6 bytes
redisplay_internal(int 0x00000000) line 9007 + 8 bytes
redisplay() line 8433 + 7 bytes
read_char(int 0x00000001, int 0x00000003, int * 0x0082fc9c, int 0x11297404, int * 0x0082fcd4) line 2430
read_key_sequence(int * 0x0082fd7c, int 0x0000001e, int 0x11297404, int 0x00000000, int 0x00000001, int 0x00000001) line 8533 + 36 bytes
command_loop_1() line 1475 + 32 bytes
internal_condition_case(int (void)* 0x0100e1da command_loop_1(void), int 0x112b1214, int (void)* 0x0100de6e cmd_error(void)) line 1352
command_loop_2() line 1270 + 21 bytes
internal_catch(int 0x112a67c4, int (void)* 0x0100e0e2 command_loop_2(void), int 0x11297404) line 1112 + 6 bytes
command_loop() line 1254
recursive_edit_1() line 969 + 5 bytes
Frecursive_edit() line 1026
main() line 1659 + 5 bytes
EMACS! mainCRTStartup + 180 bytes
KERNEL32! 77ea847c()

Re: xdisp.c problem?

[Tak Ota]

Fri, 31 Jan 2003 01:57:38 +0900 (JST): Masatake YAMATO <jet@gyve.org> wrote:

> > I tried to isolate the case from the entire circumstance, which is
> > using Mew package to view email messages.  I was not successful.  It
> > happens only when I try to view certain messages. 
> 
> My emacs gets hung, too when I moves the point to "[End of message]"
> of mew buffer. I'm using GNU/Linux. The echo area and header line are
> flushed repeatedly.

I suppose the repetitive and continuous attempt to redisplay is
causing that rapid flashing.

If you set a breakpoint in unwind_to_catch, say on the line _longjmp
(catch->jmp, 1); you should be able to catch the moment.  If you can
provide the trace information from GNU/Linux under gdb it is probably
preferable data than the one I posted.

-Tak

Re: xdisp.c problem?

[Masatake YAMATO]

> If you set a breakpoint in unwind_to_catch, say on the line _longjmp
> (catch->jmp, 1); you should be able to catch the moment.  If you can
> provide the trace information from GNU/Linux under gdb it is probably
> preferable data than the one I posted.

I've tried. I got backtrace 4 times; and I found a cycle.
In all backtraces, from #0 to #17, the called functions are same.
However, functions at #18 are different.

M-x occur #18

(backtrace 1)
     46:#18 0x0806949f in redisplay_preserve_echo_area (from_where=7) at xdisp.c:9231

(backtrace 2)
    114:#18 0x08067ea9 in redisplay () at xdisp.c:8434

(backtrace 3)
    161:#18 0x0806949f in redisplay_preserve_echo_area (from_where=2) at xdisp.c:9231

(backtrace 4)
    228:#18 0x08067ea9 in redisplay () at xdisp.c:8434

Regards,
Masatake YAMATO
p.s. I can provide backtraces log as a MIME attached file.
-----------------------------------------------------------------------
(gdb) where
#0  unwind_to_catch (catch=0xbfffede0, value=-1073746000) at eval.c:1172
#1  0x08132279 in Fsignal (error_symbol=405555460, data=1486783484) at eval.c:1547
#2  0x081220fe in args_out_of_range (a1=0, a2=0) at data.c:140
#3  0x0816dcd4 in validate_interval_range (object=1213853600, begin=0xbfffdb40, end=0xbfffdb40, force=0)
    at textprop.c:151
#4  0x0816e68d in Ftext_properties_at (position=0, object=-1073744464) at textprop.c:585
#5  0x0816e6f9 in Fget_text_property (position=0, prop=405682500, object=1213853600) at textprop.c:606
#6  0x0816e779 in get_char_property_and_overlay (position=0, prop=405682500, object=1213853600, overlay=0x0)
    at textprop.c:688
#7  0x0816e916 in Fget_char_property (position=0, prop=405682500, object=405458780) at textprop.c:704
#8  0x0816ea64 in Fnext_single_char_property_change (position=0, prop=405682500, object=405458780, limit=1367)
    at textprop.c:800
#9  0x08069a1a in set_cursor_from_row (w=0x8694028, row=0x89ab33c, matrix=0xbfffefb0, delta=0, delta_bytes=0, dy=0, 
    dvpos=0) at xdisp.c:9527
#10 0x080716ba in display_line (it=0xbfffdd80) at xdisp.c:13577
#11 0x0806d815 in try_window (window=1214857256, pos={charpos = -1073750656, bytepos = -1073751424}) at xdisp.c:10978
#12 0x0806d2ec in redisplay_window (window=1214857256, just_this_one_p=0) at xdisp.c:10617
#13 0x080698b1 in redisplay_window_0 (window=1214857256) at xdisp.c:9437
#14 0x08131fec in internal_condition_case_1 (bfun=0x8069884 <redisplay_window_0>, arg=1214857256, handlers=1479377068, 
    hfun=0x8069868 <redisplay_window_error>) at eval.c:1392
#15 0x08069866 in redisplay_windows (window=141668432) at xdisp.c:9416
#16 0x08069828 in redisplay_windows (window=141668432) at xdisp.c:9410
#17 0x08068ae1 in redisplay_internal (preserve_echo_area=1) at xdisp.c:9007
#18 0x0806949f in redisplay_preserve_echo_area (from_where=7) at xdisp.c:9231
#19 0x080df3a2 in swallow_events (do_display=1) at keyboard.c:4130
#20 0x0805858c in sit_for (sec=0, usec=0, reading=0, display=1, initial_display=1) at dispnew.c:6233
#21 0x080586ae in Fsit_for (seconds=0, milliseconds=-1073744464, nodisp=405458780) at dispnew.c:6288
#22 0x08133a0a in Ffuncall (nargs=2, args=0xbfffea30) at eval.c:2740
#23 0x0815b790 in Fbyte_code (bytestr=141340868, vector=1, maxdepth=-1073747296) at bytecode.c:709
#24 0x08133cfb in funcall_lambda (fun=1213795320, nargs=0, arg_vector=0xbfffec88) at eval.c:2927
#25 0x081338e3 in Ffuncall (nargs=1, args=0xbfffec84) at eval.c:2797
#26 0x081332ea in Fapply (nargs=2, args=0xbfffec84) at eval.c:2247
#27 0x08133ad2 in Ffuncall (nargs=3, args=0xbfffec80) at eval.c:2721
#28 0x0815b790 in Fbyte_code (bytestr=407485460, vector=2, maxdepth=-1073746816) at bytecode.c:709
#29 0x08133056 in Feval (form=136768600) at eval.c:2095
#30 0x08131df0 in Fcondition_case (args=405458780) at eval.c:1298
#31 0x0815c39d in Fbyte_code (bytestr=407485460, vector=143, maxdepth=-1073746208) at bytecode.c:891
#32 0x08133cfb in funcall_lambda (fun=1210249372, nargs=1, arg_vector=0xbffff024) at eval.c:2927
#33 0x081338e3 in Ffuncall (nargs=2, args=0xbffff020) at eval.c:2797
#34 0x08133718 in call1 (fn=405513452, arg1=1213794184) at eval.c:2536
#35 0x080df838 in timer_check (do_it_now=1) at keyboard.c:4339
#36 0x080de75d in readable_filtered_events (do_timers_now=-1073744464, filter_events=0) at keyboard.c:3390
#37 0x080e171c in get_filtered_input_pending (addr=0x82a336c, do_timers_now=1, filter_events=0) at keyboard.c:6370
#38 0x080e173b in get_input_pending (addr=0x82a336c, do_timers_now=1) at keyboard.c:6386
#39 0x080e5ec7 in detect_input_pending_run_timers (do_display=0) at keyboard.c:9746
#40 0x080dca30 in read_char (commandflag=1, nmaps=2, maps=0xbffff390, prev_event=405458780, used_mouse_menu=0xbffff3c8)
    at keyboard.c:2418
#41 0x080e3c8d in read_key_sequence (keybuf=0xbffff4f0, bufsize=30, prompt=405458780, dont_downcase_last=0, 
    can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:8531
#42 0x080dae8b in command_loop_1 () at keyboard.c:1474
#43 0x08131ef2 in internal_condition_case (bfun=0x80dad18 <command_loop_1>, handlers=405555388, 
    hfun=0x80da914 <cmd_error>) at eval.c:1351
#44 0x080dabfe in command_loop_2 () at keyboard.c:1274
#45 0x08131a95 in internal_catch (tag=405458688, func=0x80dabe0 <command_loop_2>, arg=405458780) at eval.c:1112
#46 0x080dabb4 in command_loop () at keyboard.c:1253
#47 0x080da6f3 in recursive_edit_1 () at keyboard.c:969
#48 0x080da800 in Frecursive_edit () at keyboard.c:1025
#49 0x080d915b in main (argc=1, argv=0xbffffac4) at emacs.c:1659
#50 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) c
Continuing.

Breakpoint 2, unwind_to_catch (catch=0xbffff5b0, value=1486783644) at eval.c:1143
(gdb) c
Continuing.

Breakpoint 3, unwind_to_catch (catch=0xbffff5b0, value=0) at eval.c:1172
(gdb) where
#0  unwind_to_catch (catch=0xbffff5b0, value=0) at eval.c:1172
#1  0x08132279 in Fsignal (error_symbol=405555460, data=1486783628) at eval.c:1547
#2  0x081220fe in args_out_of_range (a1=0, a2=0) at data.c:140
#3  0x0816dcd4 in validate_interval_range (object=1213853600, begin=0xbfffe3a0, end=0xbfffe3a0, force=0)
    at textprop.c:151
#4  0x0816e68d in Ftext_properties_at (position=0, object=-1073744176) at textprop.c:585
#5  0x0816e6f9 in Fget_text_property (position=0, prop=405682500, object=1213853600) at textprop.c:606
#6  0x0816e779 in get_char_property_and_overlay (position=0, prop=405682500, object=1213853600, overlay=0x0)
    at textprop.c:688
#7  0x0816e916 in Fget_char_property (position=0, prop=405682500, object=405458780) at textprop.c:704
#8  0x0816ea64 in Fnext_single_char_property_change (position=0, prop=405682500, object=405458780, limit=1367)
    at textprop.c:800
#9  0x08069a1a in set_cursor_from_row (w=0x8694028, row=0x89ab33c, matrix=0x0, delta=0, delta_bytes=0, dy=0, dvpos=0)
    at xdisp.c:9527
#10 0x080716ba in display_line (it=0xbfffe5e0) at xdisp.c:13577
#11 0x0806d815 in try_window (window=1214857256, pos={charpos = -1073748512, bytepos = -1073749280}) at xdisp.c:10978
#12 0x0806d2ec in redisplay_window (window=1214857256, just_this_one_p=0) at xdisp.c:10617
#13 0x080698b1 in redisplay_window_0 (window=1214857256) at xdisp.c:9437
#14 0x08131fec in internal_condition_case_1 (bfun=0x8069884 <redisplay_window_0>, arg=1214857256, handlers=1479377068, 
    hfun=0x8069868 <redisplay_window_error>) at eval.c:1392
#15 0x08069866 in redisplay_windows (window=141668384) at xdisp.c:9416
#16 0x08069828 in redisplay_windows (window=141668384) at xdisp.c:9410
#17 0x08068ae1 in redisplay_internal (preserve_echo_area=0) at xdisp.c:9007
#18 0x08067ea9 in redisplay () at xdisp.c:8434
#19 0x080ddd81 in read_char (commandflag=1, nmaps=2, maps=0xbffff390, prev_event=405458780, used_mouse_menu=0xbffff3c8)
    at keyboard.c:2428
#20 0x080e3c8d in read_key_sequence (keybuf=0xbffff4f0, bufsize=30, prompt=405458780, dont_downcase_last=0, 
    can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:8531
#21 0x080dae8b in command_loop_1 () at keyboard.c:1474
#22 0x08131ef2 in internal_condition_case (bfun=0x80dad18 <command_loop_1>, handlers=405555388, 
    hfun=0x80da914 <cmd_error>) at eval.c:1351
#23 0x080dabfe in command_loop_2 () at keyboard.c:1274
#24 0x08131a95 in internal_catch (tag=405458688, func=0x80dabe0 <command_loop_2>, arg=405458780) at eval.c:1112
#25 0x080dabb4 in command_loop () at keyboard.c:1253
#26 0x080da6f3 in recursive_edit_1 () at keyboard.c:969
#27 0x080da800 in Frecursive_edit () at keyboard.c:1025
#28 0x080d915b in main (argc=1, argv=0xbffffac4) at emacs.c:1659
#29 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) c
Continuing.

Breakpoint 2, unwind_to_catch (catch=0xbfffede0, value=1486784356) at eval.c:1143
(gdb) c
Continuing.

Breakpoint 3, unwind_to_catch (catch=0xbfffede0, value=-1073746000) at eval.c:1172
(gdb) where
#0  unwind_to_catch (catch=0xbfffede0, value=-1073746000) at eval.c:1172
#1  0x08132279 in Fsignal (error_symbol=405555460, data=1486784348) at eval.c:1547
#2  0x081220fe in args_out_of_range (a1=0, a2=0) at data.c:140
#3  0x0816dcd4 in validate_interval_range (object=1213853600, begin=0xbfffdbd0, end=0xbfffdbd0, force=0)
    at textprop.c:151
#4  0x0816e68d in Ftext_properties_at (position=0, object=-1073744464) at textprop.c:585
#5  0x0816e6f9 in Fget_text_property (position=0, prop=405682500, object=1213853600) at textprop.c:606
#6  0x0816e779 in get_char_property_and_overlay (position=0, prop=405682500, object=1213853600, overlay=0x0)
    at textprop.c:688
#7  0x0816e916 in Fget_char_property (position=0, prop=405682500, object=405458780) at textprop.c:704
#8  0x0816ea64 in Fnext_single_char_property_change (position=0, prop=405682500, object=405458780, limit=1367)
    at textprop.c:800
#9  0x08069a1a in set_cursor_from_row (w=0x8694028, row=0x89ab33c, matrix=0xbfffefb0, delta=0, delta_bytes=0, dy=0, 
    dvpos=0) at xdisp.c:9527
#10 0x080716ba in display_line (it=0xbfffde10) at xdisp.c:13577
#11 0x0806d815 in try_window (window=1214857256, pos={charpos = -1073750512, bytepos = -1073751280}) at xdisp.c:10978
#12 0x0806d2ec in redisplay_window (window=1214857256, just_this_one_p=0) at xdisp.c:10617
#13 0x080698b1 in redisplay_window_0 (window=1214857256) at xdisp.c:9437
#14 0x08131fec in internal_condition_case_1 (bfun=0x8069884 <redisplay_window_0>, arg=1214857256, handlers=1479377068, 
    hfun=0x8069868 <redisplay_window_error>) at eval.c:1392
#15 0x08069866 in redisplay_windows (window=141668432) at xdisp.c:9416
#16 0x08069828 in redisplay_windows (window=141668432) at xdisp.c:9410
#17 0x08068ae1 in redisplay_internal (preserve_echo_area=1) at xdisp.c:9007
#18 0x0806949f in redisplay_preserve_echo_area (from_where=2) at xdisp.c:9231
#19 0x08058610 in sit_for (sec=0, usec=0, reading=0, display=1, initial_display=1) at dispnew.c:6239
#20 0x080586ae in Fsit_for (seconds=0, milliseconds=-1073744464, nodisp=405458780) at dispnew.c:6288
#21 0x08133a0a in Ffuncall (nargs=2, args=0xbfffea30) at eval.c:2740
#22 0x0815b790 in Fbyte_code (bytestr=141340868, vector=1, maxdepth=-1073747296) at bytecode.c:709
#23 0x08133cfb in funcall_lambda (fun=1213795320, nargs=0, arg_vector=0xbfffec88) at eval.c:2927
#24 0x081338e3 in Ffuncall (nargs=1, args=0xbfffec84) at eval.c:2797
#25 0x081332ea in Fapply (nargs=2, args=0xbfffec84) at eval.c:2247
#26 0x08133ad2 in Ffuncall (nargs=3, args=0xbfffec80) at eval.c:2721
#27 0x0815b790 in Fbyte_code (bytestr=407485460, vector=2, maxdepth=-1073746816) at bytecode.c:709
#28 0x08133056 in Feval (form=136768600) at eval.c:2095
#29 0x08131df0 in Fcondition_case (args=405458780) at eval.c:1298
#30 0x0815c39d in Fbyte_code (bytestr=407485460, vector=143, maxdepth=-1073746208) at bytecode.c:891
#31 0x08133cfb in funcall_lambda (fun=1210249372, nargs=1, arg_vector=0xbffff024) at eval.c:2927
#32 0x081338e3 in Ffuncall (nargs=2, args=0xbffff020) at eval.c:2797
#33 0x08133718 in call1 (fn=405513452, arg1=1213794184) at eval.c:2536
#34 0x080df838 in timer_check (do_it_now=1) at keyboard.c:4339
#35 0x080de75d in readable_filtered_events (do_timers_now=-1073744464, filter_events=0) at keyboard.c:3390
#36 0x080e171c in get_filtered_input_pending (addr=0x82a336c, do_timers_now=1, filter_events=0) at keyboard.c:6370
#37 0x080e173b in get_input_pending (addr=0x82a336c, do_timers_now=1) at keyboard.c:6386
#38 0x080e5ec7 in detect_input_pending_run_timers (do_display=0) at keyboard.c:9746
#39 0x080dca30 in read_char (commandflag=1, nmaps=2, maps=0xbffff390, prev_event=405458780, used_mouse_menu=0xbffff3c8)
    at keyboard.c:2418
#40 0x080e3c8d in read_key_sequence (keybuf=0xbffff4f0, bufsize=30, prompt=405458780, dont_downcase_last=0, 
    can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:8531
#41 0x080dae8b in command_loop_1 () at keyboard.c:1474
#42 0x08131ef2 in internal_condition_case (bfun=0x80dad18 <command_loop_1>, handlers=405555388, 
    hfun=0x80da914 <cmd_error>) at eval.c:1351
#43 0x080dabfe in command_loop_2 () at keyboard.c:1274
#44 0x08131a95 in internal_catch (tag=405458688, func=0x80dabe0 <command_loop_2>, arg=405458780) at eval.c:1112
#45 0x080dabb4 in command_loop () at keyboard.c:1253
#46 0x080da6f3 in recursive_edit_1 () at keyboard.c:969
#47 0x080da800 in Frecursive_edit () at keyboard.c:1025
#48 0x080d915b in main (argc=1, argv=0xbffffac4) at emacs.c:1659
#49 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) c
Continuing.

Breakpoint 2, unwind_to_catch (catch=0xbffff5b0, value=1486784508) at eval.c:1143
(gdb) c
Continuing.

Breakpoint 3, unwind_to_catch (catch=0xbffff5b0, value=0) at eval.c:1172
(gdb) where
#0  unwind_to_catch (catch=0xbffff5b0, value=0) at eval.c:1172
#1  0x08132279 in Fsignal (error_symbol=405555460, data=1486784492) at eval.c:1547
#2  0x081220fe in args_out_of_range (a1=0, a2=0) at data.c:140
#3  0x0816dcd4 in validate_interval_range (object=1213853600, begin=0xbfffe3a0, end=0xbfffe3a0, force=0)
    at textprop.c:151
#4  0x0816e68d in Ftext_properties_at (position=0, object=-1073744176) at textprop.c:585
#5  0x0816e6f9 in Fget_text_property (position=0, prop=405682500, object=1213853600) at textprop.c:606
#6  0x0816e779 in get_char_property_and_overlay (position=0, prop=405682500, object=1213853600, overlay=0x0)
    at textprop.c:688
#7  0x0816e916 in Fget_char_property (position=0, prop=405682500, object=405458780) at textprop.c:704
#8  0x0816ea64 in Fnext_single_char_property_change (position=0, prop=405682500, object=405458780, limit=1367)
    at textprop.c:800
#9  0x08069a1a in set_cursor_from_row (w=0x8694028, row=0x89ab33c, matrix=0x0, delta=0, delta_bytes=0, dy=0, dvpos=0)
    at xdisp.c:9527
#10 0x080716ba in display_line (it=0xbfffe5e0) at xdisp.c:13577
#11 0x0806d815 in try_window (window=1214857256, pos={charpos = -1073748512, bytepos = -1073749280}) at xdisp.c:10978
#12 0x0806d2ec in redisplay_window (window=1214857256, just_this_one_p=0) at xdisp.c:10617
#13 0x080698b1 in redisplay_window_0 (window=1214857256) at xdisp.c:9437
#14 0x08131fec in internal_condition_case_1 (bfun=0x8069884 <redisplay_window_0>, arg=1214857256, handlers=1479377068, 
    hfun=0x8069868 <redisplay_window_error>) at eval.c:1392
#15 0x08069866 in redisplay_windows (window=141668384) at xdisp.c:9416
#16 0x08069828 in redisplay_windows (window=141668384) at xdisp.c:9410
#17 0x08068ae1 in redisplay_internal (preserve_echo_area=0) at xdisp.c:9007
#18 0x08067ea9 in redisplay () at xdisp.c:8434
#19 0x080ddd81 in read_char (commandflag=1, nmaps=2, maps=0xbffff390, prev_event=405458780, used_mouse_menu=0xbffff3c8)
    at keyboard.c:2428
#20 0x080e3c8d in read_key_sequence (keybuf=0xbffff4f0, bufsize=30, prompt=405458780, dont_downcase_last=0, 
    can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:8531
#21 0x080dae8b in command_loop_1 () at keyboard.c:1474
#22 0x08131ef2 in internal_condition_case (bfun=0x80dad18 <command_loop_1>, handlers=405555388, 
    hfun=0x80da914 <cmd_error>) at eval.c:1351
#23 0x080dabfe in command_loop_2 () at keyboard.c:1274
#24 0x08131a95 in internal_catch (tag=405458688, func=0x80dabe0 <command_loop_2>, arg=405458780) at eval.c:1112
#25 0x080dabb4 in command_loop () at keyboard.c:1253
#26 0x080da6f3 in recursive_edit_1 () at keyboard.c:969
#27 0x080da800 in Frecursive_edit () at keyboard.c:1025
#28 0x080d915b in main (argc=1, argv=0xbffffac4) at emacs.c:1659
#29 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) 

Re: xdisp.c problem?

[Masatake YAMATO]

> I've just installed the attached patch to skip such glyphs
> that come from overlay string.  Please try again.

After applying your patch, my Emacs doesn't hung!

Masatake

Re: xdisp.c problem?

[Kenichi Handa]

In article <20030130.155620.107709347.Takaaki.Ota@am.sony.com>, Tak Ota <Takaaki.Ota@am.sony.com> writes:
> Here is the complete trace to where unwind_to_catch brings us back to
> internal_condition_case and the descending starts all over again.  The
> function set_cursor_from_row is in the trace.  It was not a simple
> loop but continuous signal generation caused by the change to
> internal_condition_case.
[...]
> unwind_to_catch() line 1172
> Fsignal(int 0x112b125c, int 0x519a46dc) line 1547 + 12 bytes
> args_out_of_range(int 0x00000000, int 0x00000000) line 140 + 35 bytes
> validate_interval_range(int 0x41942000, int * 0x0082f024, int * 0x0082f024, int 0x00000000) line 151 + 8 bytes
> Ftext_properties_at(int 0x00000000, int 0x41942000) line 585 + 16 bytes
> get_char_property_and_overlay(int 0x00000000, int 0x112d38ac, int 0x0082f030, int * 0x00000000) line 688 + 12 bytes
> Fnext_single_char_property_change(int 0x00000000, int 0x112d38ac, int 0x11297404, int 0x000006f5) line 802
> set_cursor_from_row(window * 0x019f9400, glyph_row * 0x00000000, glyph_matrix * 0x01a85000, int 0x00000000, int 0x00000000, int 0x00000000, int 0x00000000) line 9527 + 24 bytes

It seems that Fnext_single_char_property_change is called
with POS == 0 in this code:

L9525:      pos = make_number (string_buffer_position (w, glyph->object,
L9526:						 string_before_pos));
L9527:      pos = Fnext_single_char_property_change (pos, Qdisplay, Qnil, limit);

That means string_buffer_position returns 0 in your case.

Hmmm, as this function checks only `display' property, that
is a likely result if the buffer contains overlay string.

I've just installed the attached patch to skip such glyphs
that come from overlay string.  Please try again.

---
Ken'ichi HANDA
handa@m17n.org

2003-01-31  Kenichi Handa  <handa@m17n.org>

	* xdisp.c (SKIP_GLYPHS): New macro.
	(set_cursor_from_row): Skip all glyphs that comes from overlay
	string.

*** xdisp.c.~1.803.~	Wed Jan 29 21:55:18 2003
--- xdisp.c	Fri Jan 31 11:43:08 2003
***************
*** 9447,9452 ****
--- 9447,9465 ----
    return Qnil;
  }
  \f
+ 
+ /* Increment GLYPH until it reaches END or CONDITION fails while
+    adding (GLYPH)->pixel_width to X. */
+ 
+ #define SKIP_GLYPHS(glyph, end, x, condition)	\
+   do						\
+     {						\
+       (x) += (glyph)->pixel_width;		\
+       ++(glyph);				\
+     }						\
+   while ((glyph) < (end) && (condition))
+ 
+ 
  /* Set cursor position of W.  PT is assumed to be displayed in ROW.
     DELTA is the number of bytes by which positions recorded in ROW
     differ from current buffer positions.  */
***************
*** 9501,9512 ****
  	  string_start = glyph;
  	  string_start_x = x;
  	  /* Skip all glyphs from string.  */
! 	  do
! 	    {
! 	      x += glyph->pixel_width;
! 	      ++glyph;
! 	    }
! 	  while (glyph < end && STRINGP (glyph->object));
  	}
      }
  
--- 9514,9520 ----
  	  string_start = glyph;
  	  string_start_x = x;
  	  /* Skip all glyphs from string.  */
! 	  SKIP_GLYPHS (glyph, end, x, STRINGP (glyph->object));
  	}
      }
  
***************
*** 9517,9544 ****
  	 are from string.  As there's no easy way to know the
  	 character position of the current glyph, find the correct
  	 glyph on point by scanning from string_start again.  */
!       Lisp_Object pos, limit;
  
!       limit = make_number (MATRIX_ROW_END_CHARPOS (row) + delta);
        glyph = string_start;
        x = string_start_x;
!       pos = make_number (string_buffer_position (w, glyph->object,
! 						 string_before_pos));
!       pos = Fnext_single_char_property_change (pos, Qdisplay, Qnil, limit);
!       while (XINT (pos) <= pt_old)
  	{
  	  /* Skip glyphs from the same string.  */
! 	  do
  	    {
! 	      x += glyph->pixel_width;
! 	      ++glyph;
  	    }
- 	  while (glyph < end
- 		 && EQ (glyph->object, string_start->object));
- 	  if (glyph == end || !STRINGP (glyph->object))
- 	    break;
- 	  string_start = glyph;
- 	  pos = Fnext_single_char_property_change (pos, Qdisplay, Qnil, limit);
  	}
      }
  
--- 9525,9566 ----
  	 are from string.  As there's no easy way to know the
  	 character position of the current glyph, find the correct
  	 glyph on point by scanning from string_start again.  */
!       Lisp_Object limit;
!       Lisp_Object string;
!       int pos;
  
!       limit = make_number (pt_old + 1);
!       end = glyph;
        glyph = string_start;
        x = string_start_x;
!       string = glyph->object;
!       pos = string_buffer_position (w, string, string_before_pos);
!       /* If STRING is from overlay, LAST_POS == 0.  We skip such glyphs
! 	 because we always put cursor after overlay strings.  */
!       while (pos == 0 && glyph < end)
! 	{
! 	  string = glyph->object;
! 	  SKIP_GLYPHS (glyph, end, x, EQ (glyph->object, string));
! 	  if (glyph < end)
! 	    pos = string_buffer_position (w, glyph->object, string_before_pos);
! 	}
! 
!       while (glyph < end)
  	{
+ 	  pos = XINT (Fnext_single_char_property_change
+ 		      (make_number (pos), Qdisplay, Qnil, limit));
+ 	  if (pos > pt_old)
+ 	    break;
  	  /* Skip glyphs from the same string.  */
! 	  string = glyph->object;
! 	  SKIP_GLYPHS (glyph, end, x, EQ (glyph->object, string));
! 	  /* Skip glyphs from an overlay.  */
! 	  while (glyph < end
! 		 && ! string_buffer_position (w, glyph->object, pos))
  	    {
! 	      string = glyph->object;
! 	      SKIP_GLYPHS (glyph, end, x, EQ (glyph->object, string));
  	    }
  	}
      }

Re: xdisp.c problem?

[Masatake YAMATO]

I wrote:
> After applying your patch, my Emacs doesn't hung!

Handa-san wrote:
> Thank you for testing it.  Do you mean that cursor is also
> displayed on the correct place?

Yes.

--- *Mew messages* buffer ---
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel[1]
[End of message][2]
--- *Mew messages* buffer ---

When I press C-f, the point at [1] moves to [2].
I think this is the correct movement.

Masatake YAMATO

Re: xdisp.c problem?

[Kenichi Handa]

In article <20030131.114747.21602206.jet@gyve.org>, Masatake YAMATO <jet@gyve.org> writes:
>>  I've just installed the attached patch to skip such glyphs
>>  that come from overlay string.  Please try again.

> After applying your patch, my Emacs doesn't hung!

Thank you for testing it.  Do you mean that cursor is also
displayed on the correct place?

---
Ken'ichi HANDA
handa@m17n.org

Re: xdisp.c problem?

[Tak Ota]

Fri, 31 Jan 2003 12:58:37 +0900 (JST): Kenichi Handa <handa@m17n.org> wrote:

> It seems that Fnext_single_char_property_change is called
> with POS == 0 in this code:
> 
> L9525:      pos = make_number (string_buffer_position (w, glyph->object,
> L9526:						 string_before_pos));
> L9527:      pos = Fnext_single_char_property_change (pos, Qdisplay, Qnil, limit);
> 
> That means string_buffer_position returns 0 in your case.
> 
> Hmmm, as this function checks only `display' property, that
> is a likely result if the buffer contains overlay string.
> 
> I've just installed the attached patch to skip such glyphs
> that come from overlay string.  Please try again.

I've just tested the patch already applied xdips.c from the CVS this
morning.  It works fine now, even on this inferior system too.  Thank
you.

-Tak

Re: xdisp.c problem?

[Richard Stallman]

    Ftext_properties_at(int 0x00000000, int 0x41942000) line 585 + 16 bytes
    get_char_property_and_overlay(int 0x00000000, int 0x112d38ac, int 0x0082f030, int * 0x00000000) line 688 + 12 bytes
    Fnext_single_char_property_change(int 0x00000000, int 0x112d38ac, int 0x11297404, int 0x000006f5) line 802

Which of these position arguments are valid buffer positions?
You need to compare them with the begv and zv fields in the
buffer object.