bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere

[Eli Zaretskii <eliz@gnu.org>]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 18 Feb 2013 10:41:31 +0400
> 
> Emacs reliably crashes when [s]tealing a file that's opened in another
> instance. I can only reproduce this when the buffer opens in mmm-mode
> (so the bug may be related to indirect buffers), and apparently mmm-mode
> modifies the buffer in some way automatically, so the prompt to
> steal/proceed/quit is shown as soon as I open the file.
> 
> I think this is the first situation I've seen Emacs crash, in quite a
> while.
> 
> 
> (gdb) xbacktrace
> "put-text-property" (0xffff9a20)
> "jit-lock-refontify" (0xffff9c00)
> "jit-lock-mode" (0xffff9e00)
> "jit-lock-register" (0xffff9fd0)
> "font-lock-turn-on-thing-lock" (0xffffa1b0)
> "font-lock-mode-internal" (0xffffa380)
> "font-lock-default-function" (0xffffa550)
> "font-lock-mode" (0xffffa720)
> "turn-on-font-lock" (0xffffa8d0)
> "turn-on-font-lock-if-desired" (0xffffaa90)
> "global-font-lock-mode-enable-in-buffers" (0xffffaca8)
> "run-hooks" (0xffffad68)
> "apply" (0xffffaec0)
> "run-mode-hooks" (0xffffaff0)
> "html-erb-mode" (0xffffb2a8)
> "funcall" (0xffffb2a0)
> "save-current-buffer" (0xffffb418)
> "unwind-protect" (0xffffb538)
> "let" (0xffffb6d8)
> "if" (0xffffb7e8)
> "let" (0xffffb9a8)
> "mmm-update-mode-info" (0xffffbaf0)
> "if" (0xffffbcc8)
> ---Type <return> to continue, or q <return> to quit---
> "if" (0xffffbdd8)
> "mmm-mode-on" (0xffffbf20)
> "cond" (0xffffc0e8)
> "mmm-mode-on-maybe" (0xffffc2d8)
> "funcall" (0xffffc2d0)
> "progn" (0xffffc428)
> "condition-case" (0xffffc6a8)
> "while" (0xffffc7d8)
> "let" (0xffffc978)
> "progn" (0xffffca88)
> "mmm-run-major-mode-hook" (0xffffcbd0)
> "save-current-buffer" (0xffffcdb8)
> "progn" (0xffffcec8)
> "if" (0xffffcfc8)
> "while" (0xffffd0f8)
> "let" (0xffffd298)
> "progn" (0xffffd3a8)
> "mmm-check-changed-buffers" (0xffffd590)
> (gdb)
> 
> ===
> 
> bt full is too long for my terminal, so here's the top. Let me know if
> it's not enough, I'll try to increase the history limit or whatever.
> 
> (gdb) bt full
> #0  add_properties (plist=plist@entry=31577430, i=i@entry=0x0, 
>     object=object@entry=12438597) at textprop.c:378
>         tail1 = 31577430
>         tail2 = <optimized out>
>         sym1 = 12306530
>         val1 = 12067362
>         changed = <optimized out>
>         found = 0

Can you recompile without optimizations, and show the backtrace from
that build?  Thanks.