bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21428: 24.5; Crash of emacs on OS X, installed via homebrew cask


From: Eli Zaretskii
Subject: bug#21428: 24.5; Crash of emacs on OS X, installed via homebrew cask
Date: Mon, 21 Sep 2015 16:18:45 +0300

[Returning the discussion to the bug tracker.]

> From: Rainer M Krug <Rainer@krugs.de>
> Date: Mon, 21 Sep 2015 14:32:23 +0200
> 
> > I cannot reproduce this, unfortunately.  I cannot even successfully
> > load your init files, something is missing, even though I downloaded
> > cask and pallet.
> >
> > Any chance of you coming up with a recipe that starts from "emacs -Q"?
> >
> > If not, can you compile Emacs with debug info, run it under the
> > debugger, and tell me values of some variables I need to see?
> 
> The crash is occurring very irregular and I am working while triggering
> it - and I haven't found a reliable recipe yet.
> 
> The easiest would be to compile with debug info - I'll see how I can do
> it using homebrew or directly.
> 
> Could you give me the options I should use in the configure?

I don't know how Emacs is built on OS X, sorry.  I can only tell that
the compiler switches should include -g and NOT include -s.  You
should be able to see the compiler switches in src/Makefile.

If this is somehow not enough, I can go with "printf debugging", if
it's okay with you.  That is, assuming that adding a line such as

  fprintf (stderr, "something to print\n");

to some place in the C code, then recompiling Emacs and running it
will display the specified text.

The infinite recursion in this last crash happens here:

  /* If we reached the end of the object we've been iterating (e.g., a
     display string or an overlay string), and there's something on
     IT->stack, proceed with what's on the stack.  It doesn't make
     sense to return false if there's unprocessed stuff on the stack,
     because otherwise that stuff will never be displayed.  */
  if (!success_p && it->sp > 0)
    {
      set_iterator_to_next (it, false);
      success_p = get_next_display_element (it);  <<<<<<<<<<<<<<<<<<<<<<
    }

  /* Value is false if end of buffer or string reached.  */
  return success_p;

This is the end of the function get_next_display_element, around line
7190 in xdisp.c.  For some reason, the call to set_iterator_to_next
leaves us at the same place of the same object we were before the
call.  I need to understand why that happens, and fix this code not to
do that.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]