Eli Zaretskii <eliz@gnu.org> writes:

> [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.

Effectively as under Linux.

> 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.

I used

,----
| CFLAGS="-ggdb3 -O0" CXXFLAGS="-ggdb3 -O0" LDFLAGS="-ggdb3" ./configure --enable-checking --with-gif=no --prefix=$HOME/local/apps/emacs-24.4/
`----

As I found this here
http://emacs.stackexchange.com/questions/4213/how-to-compile-emacs-with-debug-symbols

>
> 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.

Let me know what I should put where and I can do it.

>
> 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.

I am at the moment compiling with the above mentioned command

,----
| CFLAGS="-ggdb3 -O0" CXXFLAGS="-ggdb3 -O0" LDFLAGS="-ggdb3" ./configure --enable-checking
`----

but I can compile anytime again.

Rainer

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982