bug#23049: 25.0.92; Crash in find_interval when performing textual replacement

[John Wiegley]

I don't yet have a reliable reproduction for this.

1. After using emacs-25 for a long time, I tried to do:

    replace-regexp "fun var => @" ""

2. This resulted in the following trace:

--8<---------------cut here---------------start------------->8---
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib              0x00007fff853a5c82 __kill + 10
1   org.gnu.Emacs                       0x00000001000d3423 emacs_abort + 19
2   org.gnu.Emacs                       0x00000001001a5f2c ns_term_shutdown + 
124
3   org.gnu.Emacs                       0x00000001000b6b95 shut_down_emacs + 261
4   org.gnu.Emacs                       0x00000001000b6995 
terminate_due_to_signal + 85
5   org.gnu.Emacs                       0x00000001000d4d46 
deliver_fatal_thread_signal + 134
6   org.gnu.Emacs                       0x00000001000d5ab3 handle_sigsegv + 147
7   libsystem_platform.dylib            0x00007fff8b58bf1a _sigtramp + 26
8   org.gnu.Emacs                       0x0000000100184373 find_interval + 211
9   org.gnu.Emacs                       0x0000000100186017 set_point_both + 103
10  org.gnu.Emacs                       0x00000001000ff365 Freplace_match + 3797
11  org.gnu.Emacs                       0x0000000100135d8e Ffuncall + 1086
12  org.gnu.Emacs                       0x000000010016f10d exec_byte_code + 2301
13  org.gnu.Emacs                       0x00000001001369de funcall_lambda + 862
14  org.gnu.Emacs                       0x0000000100135bd4 Ffuncall + 644
15  org.gnu.Emacs                       0x000000010016f10d exec_byte_code + 2301
16  org.gnu.Emacs                       0x00000001001369de funcall_lambda + 862
17  org.gnu.Emacs                       0x0000000100135bd4 Ffuncall + 644
18  org.gnu.Emacs                       0x000000010016f10d exec_byte_code + 2301
19  org.gnu.Emacs                       0x00000001001369de funcall_lambda + 862
20  org.gnu.Emacs                       0x0000000100135bd4 Ffuncall + 644
21  org.gnu.Emacs                       0x000000010012fd9a 
Ffuncall_interactively + 58
22  org.gnu.Emacs                       0x0000000100135c63 Ffuncall + 787
23  org.gnu.Emacs                       0x000000010013581d Fapply + 573
24  org.gnu.Emacs                       0x00000001001305bd Fcall_interactively 
+ 2061
25  org.gnu.Emacs                       0x0000000100135d54 Ffuncall + 1028
26  org.gnu.Emacs                       0x000000010016f10d exec_byte_code + 2301
27  org.gnu.Emacs                       0x0000000100135bd4 Ffuncall + 644
28  org.gnu.Emacs                       0x00000001001363bd call1 + 45
29  org.gnu.Emacs                       0x00000001000ba4ee command_loop_1 + 1966
30  org.gnu.Emacs                       0x0000000100134776 
internal_condition_case + 70
31  org.gnu.Emacs                       0x00000001000cb070 command_loop_2 + 48
32  org.gnu.Emacs                       0x00000001001342d6 internal_catch + 54
33  org.gnu.Emacs                       0x00000001000b940e command_loop + 158
34  org.gnu.Emacs                       0x00000001000b9325 recursive_edit_1 + 
101
35  org.gnu.Emacs                       0x00000001000b954c Frecursive_edit + 220
36  org.gnu.Emacs                       0x00000001000b821c main + 5660
37  org.gnu.Emacs                       0x0000000100002234 start + 52
--8<---------------cut here---------------end--------------->8---

I'll rebuild with debugging and run Emacs under the debugger to keep an eye
out, but reading it looks like we're running into a situation where 'tree' is
NULL. By building optimized, I think I just lost the assertion.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2