Re: Emacs (HEAD) crash on M$ (XP) built with MinGW

[dhruva <dhruvakm@gmail.com>]

Hi,
 I am now able to reproduce (on M$).
1. run emacs with default frame
2. Open a file with font-lock (some mid sized 'C' file)
3. Maximize the frame
4. scroll down using arrow with the cursor in the 1st column
5. On reaching the last line in the visible frame (not file), the crash happens

The following patch fixes this crash (but I do not know why it is NULL):

diff --git a/src/xdisp.c b/src/xdisp.c
index 47ba85f..f9d34c8 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -6240,6 +6240,12 @@ next_element_from_string (it)
 {
   struct text_pos position;

+  /* if string is NULL, nothing much we can do */
+  if (NULL == it->string)
+    {
+      return 0;
+    }
+
   xassert (STRINGP (it->string));
   xassert (IT_STRING_CHARPOS (*it) >= 0);
   position = it->current.string_pos;

-dhruva

On Tue, Oct 21, 2008 at 9:12 AM, dhruva <dhruvakm@gmail.com> wrote:
> Hello,
>
> On Mon, Oct 20, 2008 at 8:11 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> Date: Mon, 20 Oct 2008 18:08:15 +0530
>>> From: dhruva <dhruvakm@gmail.com>
>>>
>>>  I am still seeing the elusive and infrequent crash. I open a 'C'
>>> file, maximize the frame and use the page down to scroll down or down
>>> arrow. I keep hitting this crash off and now. The tried getting 'xbt'
>>> and could not.
>>
>> xbacktrace will not give you any useful information when the crash is
>> inside redisplay, at least not normally, because redisplay is not
>> normally triggered by Lisp code.  Redisplay is what Emacs normally
>> does when it is idle (on the C level).
>>
>>> (gdb) bt
>>> #0  0x0103ca47 in next_element_from_string (it=0x82e1ac) at xdisp.c:6263
>>> #1  0x0103b03e in get_next_display_element (it=0x82e1ac) at xdisp.c:5655
>>> #2  0x0103591d in init_from_display_pos (it=0x82e1ac, w=0x38f0e00,
>>> pos=0x3af23e0) at xdisp.c:3035
>>
>> Is this optimized build or unoptimized one?  If the former, please try
>
> built with '--no-opt' (disabled optimization)
>
>> If your xdisp.c is current, and assuming that this is an unoptimized
>> build (and so the backtrace is trustworthy), the problem seems to be
>> with trying to display something based on some string, which is stored
>> at it->string.  Could you please see what string is that, and what is
>> its contents?  That might give us a clue about whodunit.
>
> Sure, I will look at those more closely. It happens when I open a 'C' file with
> global-font-lock enabled. I will try to get stack dumps with all extra
> information.



-- 
Contents reflect my personal views only!