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

[Stefan Heitmann <sh@bytekomplex.de>]

Thank you very much for your help...

I think I understand roughly the issue and it makes sense that you can't do anything here... But I think, I could file another bug report for the repo maintainer of the arch package 😉

Thanks again

Stefan

-----Ursprüngliche Nachricht-----
Von: Yuan Fu <casouri@gmail.com> 
Gesendet: 22 April 2024 08:14
An: Eli Zaretskii <eliz@gnu.org>
Cc: Stefan Heitmann <sh@bytekomplex.de>; 70438@debbugs.gnu.org
Betreff: Re: bug#70438: Emacs error 6 abort when starting rust-ts-mode



> 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