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

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

bug#70438: Emacs error 6 abort when starting rust-ts-mode


From: Yuan Fu
Subject: bug#70438: Emacs error 6 abort when starting rust-ts-mode
Date: Sun, 21 Apr 2024 16:57:46 -0700


> On Apr 20, 2024, at 9:47 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Sat, 20 Apr 2024 15:20:41 -0700
>> Cc: Stefan Heitmann <sh@bytekomplex.de>,
>> 70438@debbugs.gnu.org
>> 
>> 
>> 
>>> On Apr 20, 2024, at 2:36 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> 
>>>> From: Yuan Fu <casouri@gmail.com>
>>>> Date: Sat, 20 Apr 2024 01:28:48 -0700
>>>> Cc: Stefan Heitmann <sh@bytekomplex.de>,
>>>> 70438@debbugs.gnu.org
>>>> 
>>>>> Yuan, can you please look into this?  It seems the latest versions of
>>>>> tree-sitter made some incompatible ABI change (without changing the
>>>>> shared-library version, I guess? not nice!), so can we have some
>>>>> workaround for this?
>>>> 
>>>> I think tree-sitter people are working to fix this [1]. I don’t think we 
>>>> can do much here, AFAICT tree-site changed ABI without bumping ABI 
>>>> version, and Arch and Gentoo are serving old Emacs build this new 
>>>> tree-sitter so, which is incompatible and crashed Emacs. We can’t really 
>>>> do anything to the Emacs build on people’s machines (though, who knows, 
>>>> maybe you CAN cask spells and flip bits).
>>>> 
>>>> [1] https://github.com/tree-sitter/tree-sitter/issues/3296
>>> 
>>> It isn't clear to me what would be their solution.  Couldn't we at
>>> least reject these new versions at configure time, until they fix the
>>> issue?
>> 
>> From what I understand, rebuilding Emacs with the new header file should fix 
>> the issue? Even if we push some change, users need to rebuild Emacs anyway.
> 
> I didn't mean to avoid rebuilding Emacs -- that's impossible when
> changes are made on the C level.  I meant to make our sources work
> with both old and new ABIs.
> 
> But maybe I don't have a clear idea of what exactly was the
> incompatible change.  Can you describe it here?  Is it the signature
> of one or more tree-sitter functions, or is it something else?

From what I understand, they changed a struct in the public interface [1]. So 
now the ABI changed. But they didn’t change the ABI version, and Arch and 
Gentoo swiftly replaced the old libtree-sitter.so with the new 
libtree-sitter.so. Then the old Emacs loaded the new libtree-sitter.so (which 
has a new ABI) and crashed.

Our code is still perfectly compatible with the new tree-sitter code; the 
changed field in that struct doesn’t affect us. The incompatibility is at the 
binary level.

[1] 
https://github.com/tree-sitter/tree-sitter/commit/09d2b23a640c60449b2b55ecae47d6483da82c95

Yuan




reply via email to

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