If it loads the same .emacs, that is good enough.
Ok, attached.
> So this seems to say that there's at least one overlay string at
> > buffer position 1295. Is that reasonable? What was the current
> > buffer when this crashed? You can find that out by typing this at GDB
> > prompt:
> > (gdb) pp current_buffer->name_
> (gdb) pp current_buffer->name_
> Cannot access memory at address 0x8b6a00
How about this:
(gdb) p current_buffer->name_
(gdb) xtype
(Note: "p", not "pp".)
If the last command says it's a Lisp string, display the contents of
'struct Lisp_String' whose address it shows.
(gdb) p current_buffer->name_
$22 = 101548849
(gdb) xtype
Lisp_String
(gdb) xstring current_buffer->name_
$23 = (struct Lisp_String *) 0x60d8330
"cdm_wrapper.cc"
Did that buffer have any minor mode or some other optional feature
turned on, in addition to C++ Mode?
See attached b-g-e.txt, in which the current buffer is the same .cc file in my HEAD session loading the same .emacs as the crashed one.
> Possibly interestingly, if I print p current_buffer->text->beg[0]@100000 to
> emit the entire buffer, I see this text starting at char 1675:
>
http://go", '\000' <repeats 2000 times>, "/b
> Those 2000 NULs are definitely out of place (the URL should have started
> with
http://go/b) but I don't know if that's a debugging artifact, or what.
This could be the gap, you should see its position and size like this:
(gdb) p current_buffer->text->gpt
(gdb) p current_buffer->text->gap_size
Yep, looks like it:
(gdb) p current_buffer->text->gpt
$24 = 1684
(gdb) p current_buffer->text->gap_size
$25 = 2000
> > (gdb) frame 6
> > #6 0x0000000000447aa1 in pop_it (it=0x7fff2251f1e0) at xdisp.c:5769
> > 5769 bidi_pop_it (&it->bidi_it);
> > (gdb) pgrowx it->glyph_row
> You can't do that without a process to debug.
So are you debugging a core dump?
Yes.
-a