GNU bug report logs -
#77924
31.0.50; [Feature branch] Change marker implementation
Previous Next
Full log
Message #20 received at 77924 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>
>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>
>>>> Are there any backward-incompatible changes with this?
>>>
>>> None I'm aware of.
>>>
>>>> Do all the tests still pass as well as they did before these changes?
>>>
>>> I got a SEGV in buffer-tests right now when I checked again that went
>>> away an a second run. So I'll have to check that.
>>
>> SUMMARY OF TEST RESULTS
>> -----------------------
>> Files examined: 530
>> Ran 8041 tests, 7765 results as expected, 0 unexpected, 276 skipped
>> [scratch/text-index] gerd <at> mini 2025-04-19 22:51
>>
>> Now fixed.
>
> Commit message:
A warning: the branch currently contains a bug that can lead to a stack
overflow that looks like this:
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x16b0ffff0)
frame #0: 0x000000010451bc38 emacs`ensure_charpos_indexed(b=0x0000000107280d28, charpos=4415031360) at text-index.c:356
frame #1: 0x000000010451bb10 emacs`text_index_charpos_to_bytepos(b=0x0000000107280840, charpos=25980) at text-index.c:621:3
frame #2: 0x00000001046cc1d0 emacs`marker_vector_bytepos(m=0x0000000107280d28) at marker-vector.c:323:10
frame #3: 0x0000000104529aec emacs`marker_byte_position(marker=(struct Lisp_Marker *) $52 = 0x0000000107280d28) at marker.c:376:29
frame #4: 0x000000010451cfb4 emacs`BUF_PT_BYTE(buf=0x0000000107280840) at buffer.h:909:6
!gud 909:6:/Users/gerd/emacs/github/cl-packages/src/buffer.h
* frame #5: 0x000000010451bdec emacs`narrow_charpos_bounds(b=0x0000000107280840, prev=0x000000016b100178, next=0x000000016b100168, charpos=25980) at text-index.c:549:42
frame #6: 0x000000010451bb78 emacs`text_index_charpos_to_bytepos(b=0x0000000107280840, charpos=25980) at text-index.c:628:23
frame #7: 0x00000001046cc1d0 emacs`marker_vector_bytepos(m=0x0000000107280d28) at marker-vector.c:323:10
frame #8: 0x0000000104529aec emacs`marker_byte_position(marker=(struct Lisp_Marker *) $52 = 0x0000000107280d28) at marker.c:376:29
frame #9: 0x000000010451cfb4 emacs`BUF_PT_BYTE(buf=0x0000000107280840) at buffer.h:909:6
frame #10: 0x000000010451bdec emacs`narrow_charpos_bounds(b=0x0000000107280840, prev=0x000000016b1002c8, next=0x000000016b1002b8, charpos=25980) at text-index.c:549:42
frame #11: 0x000000010451bb78 emacs`text_index_charpos_to_bytepos(b=0x0000000107280840, charpos=25980) at text-index.c:628:23
frame #12: 0x00000001046cc1d0 emacs`marker_vector_bytepos(m=0x0000000107280d28) at marker-vector.c:323:10
frame #13: 0x0000000104529aec emacs`marker_byte_position(marker=(struct Lisp_Marker *) $52 = 0x0000000107280d28) at marker.c:376:29
frame #14: 0x000000010451cfb4 emacs`BUF_PT_BYTE(buf=0x0000000107280840) at buffer.h:909:6
The reason for that is that functions like BUF_PT (and maybe others) are
"too smart", in the case of indirect buffers, for what I need in the
text index. I'll fix that a bit later today.
This bug report was last modified 105 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.