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 23:13:56 -0700


> On Apr 21, 2024, at 10:54 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Sun, 21 Apr 2024 16:57:46 -0700
>> Cc: Stefan Heitmann <sh@bytekomplex.de>,
>> 70438@debbugs.gnu.org
>> 
>>> 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.
> 
> And that struct is declared on the tree-sitter include file?  If so,
> the only thing we can do is reject the bad version of tree-sitter at
> configure time, I think.  This assumes that when they change the ABI
> version, they will also bump the version of the library, so the test
> for the bad version will only discover the ones that have an
> incompatible ABI.
> 
> Can you add such a test to configure.ac?
> 
> (We could theoretically also fail the compilation, using the #error
> directive, but AFAICT the tree-sitter header files don't declare any
> version-related symbols, so we cannot check the library version at
> compile time.)

There’s really no “bad” version—if someone downloads Emacs source and the new 
version of tree-sitter library (0.22.5), and compiles Emacs with it, Emacs 
wouldn’t crash. Emacs only crashes when it’s built with the old tree-sitter 
header, and loads a new tree-sitter .so file (which has incompatible ABI but 
has the same ABI version). We obviously can’t do anything to the already built 
Emacs to make it compatible with the new libtree-sitter.so; and any newly-built 
Emacs will not have issues. So I don’t really know what can we do here.

Yuan




reply via email to

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