bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#23013: 25.0.92; assertion failure on marker outside text range in ec


From: Stefan Kangas
Subject: bug#23013: 25.0.92; assertion failure on marker outside text range in echo area
Date: Tue, 11 Aug 2020 20:33:52 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ken Raeburn <raeburn@permabit.com>
>> Date: Fri, 22 Apr 2016 17:01:37 -0400
>>
>> No more than half an hour after I sat here wondering how many days
>> without a crash might suggest that maybe the change I reverted was
>> actually related to the crash, Emacs crashed; the same way as before, an
>> assertion failure on a marker position in " *Echo Area 0*", while
>> switching between buffers; the last stuff I typed was
>>
>>   C-x b e @ M-backspace return
>>
>> (I.e., switch buffer, start typing a partial name, notice the default is
>> what I want so delete what I typed, hit return.)
>>
>> The w->pointm marker has charpos and bytepos set to 41 but the buffer
>> text field has gpt, z, gpt_byte, z_byte, all set to 1.
>>
>> I've been running commit a1f221b, with d82f24b reverted, configured
>> with:
>>   '--prefix=/permabit/user/raeburn/dev/emacs/emacs-25/lx/Inst-5725167'
>>   '--with-x-toolkit=lucid' '--enable-checking' 'CPPFLAGS=-DMARKER_DEBUG'
>>   '--without-sound'
>>
>> The marker debugging code hasn't flagged anything.
>
> MARKER_DEBUG is for hunting a different kind of problems, those with
> converting byte positions to character positions and vice versa.  So
> it's little wonder it didn't flag anything.
>
> Needless to say, this never happened to me, although I use echo-area
> buffers as much as anyone else.  Not sure what this tells us.
>
> I think at this point, the only way to find this elusive bug is to
> trace updates to markers when the buffer text of the echo-area buffers
> is shrunk.  It is also possible that the problem happens because we
> switch the echo-area buffers, but do not update the markers when we
> do.  I would suggest to add some tracing code, perhaps check_markers
> or similar, to the places that are involved in the above events, and
> see what that tells us.
>
> Thanks.

That was over 4 years ago.

Have you seen this crash since, or made any progress in debugging it?

Best regards,
Stefan Kangas





reply via email to

[Prev in Thread] Current Thread [Next in Thread]