>
> Thanks.  But I'd like to see the report from your normal session,
> invoked just as you invoke those that crash.
>

Of course now I don't have such a session b/c I'm running w/ git HEAD :)

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


>   (gdb) p current_buffer->text->beg[1200]@100
>

 (gdb) p current_buffer->text->beg[1200]@100
$1 = "num to avoid later static_cast in\n// PluginInstance.\nenum
MediaKeyError {\n  kUnknownError = 1,\n  kCl"
which tells me the current buffer was an edited version of
http://src.chromium.org/viewvc/chrome/trunk/src/webkit/media/crypto/ppapi/cdm_wrapper.cc?view=markup(which
I can't share in its entirety).  FWIW, there's nothing
non-7-bit-ascii in this file, and nothing that should have triggered any
bidi-specific logic.  It's just a cc-mode C++ file.

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.

If I load the modified buffer into my HEAD session (overlays-at 1295)
returns nil.

Also, what do the following commands produce?
>   (gdb) frame 6
>   (gdb) pgrowx it->glyph_row
>
>>

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

Cheers,
-a