* xdisp.c problem? @ 2003-01-29 23:33 Tak Ota 2003-01-30 0:00 ` Kenichi Handa 0 siblings, 1 reply; 16+ messages in thread From: Tak Ota @ 2003-01-29 23:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: xdisp.c problem? 2003-01-29 23:33 xdisp.c problem? Tak Ota @ 2003-01-30 0:00 ` Kenichi Handa 2003-01-30 1:41 ` Tak Ota 0 siblings, 1 reply; 16+ messages in thread From: Kenichi Handa @ 2003-01-30 0:00 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: xdisp.c problem? 2003-01-30 0:00 ` Kenichi Handa @ 2003-01-30 1:41 ` Tak Ota 2003-01-30 3:51 ` Kenichi Handa 2003-01-30 16:57 ` Masatake YAMATO 0 siblings, 2 replies; 16+ messages in thread From: Tak Ota @ 2003-01-30 1:41 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: xdisp.c problem? 2003-01-30 1:41 ` Tak Ota @ 2003-01-30 3:51 ` Kenichi Handa 2003-01-30 17:39 ` Tak Ota 2003-01-30 21:13 ` Tak Ota 2003-01-30 16:57 ` Masatake YAMATO 1 sibling, 2 replies; 16+ messages in thread From: Kenichi Handa @ 2003-01-30 3:51 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: xdisp.c problem? 2003-01-30 3:51 ` Kenichi Handa @ 2003-01-30 17:39 ` Tak Ota 2003-01-30 21:13 ` Tak Ota 1 sibling, 0 replies; 16+ messages in thread From: Tak Ota @ 2003-01-30 17:39 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: xdisp.c problem? 2003-01-30 3:51 ` Kenichi Handa 2003-01-30 17:39 ` Tak Ota @ 2003-01-30 21:13 ` Tak Ota 2003-01-30 23:56 ` Tak Ota 1 sibling, 1 reply; 16+ messages in thread From: Tak Ota @ 2003-01-30 21:13 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: xdisp.c problem? 2003-01-30 21:13 ` Tak Ota @ 2003-01-30 23:56 ` Tak Ota 2003-01-31 3:58 ` Kenichi Handa 2003-01-31 19:19 ` Richard Stallman 0 siblings, 2 replies; 16+ messages in thread From: Tak Ota @ 2003-01-30 23:56 UTC (permalink / raw) Cc: emacs-devel 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() ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: xdisp.c problem? 2003-01-30 23:56 ` Tak Ota @ 2003-01-31 3:58 ` Kenichi Handa 2003-01-31 2:47 ` Masatake YAMATO 2003-01-31 17:34 ` Tak Ota 2003-01-31 19:19 ` Richard Stallman 1 sibling, 2 replies; 16+ messages in thread From: Kenichi Handa @ 2003-01-31 3:58 UTC (permalink / raw) Cc: emacs-devel 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)); } } } ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: xdisp.c problem? 2003-01-31 3:58 ` Kenichi Handa @ 2003-01-31 2:47 ` Masatake YAMATO 2003-01-31 6:05 ` Kenichi Handa 2003-01-31 17:34 ` Tak Ota 1 sibling, 1 reply; 16+ messages in thread From: Masatake YAMATO @ 2003-01-31 2:47 UTC (permalink / raw) Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: xdisp.c problem? 2003-01-31 2:47 ` Masatake YAMATO @ 2003-01-31 6:05 ` Kenichi Handa 2003-01-31 6:01 ` Masatake YAMATO 0 siblings, 1 reply; 16+ messages in thread From: Kenichi Handa @ 2003-01-31 6:05 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: xdisp.c problem? 2003-01-31 6:05 ` Kenichi Handa @ 2003-01-31 6:01 ` Masatake YAMATO 0 siblings, 0 replies; 16+ messages in thread From: Masatake YAMATO @ 2003-01-31 6:01 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: xdisp.c problem? 2003-01-31 3:58 ` Kenichi Handa 2003-01-31 2:47 ` Masatake YAMATO @ 2003-01-31 17:34 ` Tak Ota 1 sibling, 0 replies; 16+ messages in thread From: Tak Ota @ 2003-01-31 17:34 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: xdisp.c problem? 2003-01-30 23:56 ` Tak Ota 2003-01-31 3:58 ` Kenichi Handa @ 2003-01-31 19:19 ` Richard Stallman 1 sibling, 0 replies; 16+ messages in thread From: Richard Stallman @ 2003-01-31 19:19 UTC (permalink / raw) Cc: handa 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: xdisp.c problem? 2003-01-30 1:41 ` Tak Ota 2003-01-30 3:51 ` Kenichi Handa @ 2003-01-30 16:57 ` Masatake YAMATO 2003-01-31 0:35 ` Tak Ota 1 sibling, 1 reply; 16+ messages in thread From: Masatake YAMATO @ 2003-01-30 16:57 UTC (permalink / raw) Cc: handa > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: xdisp.c problem? 2003-01-30 16:57 ` Masatake YAMATO @ 2003-01-31 0:35 ` Tak Ota 2003-01-31 2:16 ` Masatake YAMATO 0 siblings, 1 reply; 16+ messages in thread From: Tak Ota @ 2003-01-31 0:35 UTC (permalink / raw) Cc: handa 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: xdisp.c problem? 2003-01-31 0:35 ` Tak Ota @ 2003-01-31 2:16 ` Masatake YAMATO 0 siblings, 0 replies; 16+ messages in thread From: Masatake YAMATO @ 2003-01-31 2:16 UTC (permalink / raw) Cc: handa > 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) ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2003-01-31 19:19 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2003-01-29 23:33 xdisp.c problem? Tak Ota 2003-01-30 0:00 ` Kenichi Handa 2003-01-30 1:41 ` Tak Ota 2003-01-30 3:51 ` Kenichi Handa 2003-01-30 17:39 ` Tak Ota 2003-01-30 21:13 ` Tak Ota 2003-01-30 23:56 ` Tak Ota 2003-01-31 3:58 ` Kenichi Handa 2003-01-31 2:47 ` Masatake YAMATO 2003-01-31 6:05 ` Kenichi Handa 2003-01-31 6:01 ` Masatake YAMATO 2003-01-31 17:34 ` Tak Ota 2003-01-31 19:19 ` Richard Stallman 2003-01-30 16:57 ` Masatake YAMATO 2003-01-31 0:35 ` Tak Ota 2003-01-31 2:16 ` Masatake YAMATO
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.