GNU bug report logs - #70438
Emacs error 6 abort when starting rust-ts-mode

Previous Next

Package: emacs;

Reported by: Stefan Heitmann <sh <at> bytekomplex.de>

Date: Wed, 17 Apr 2024 16:12:08 UTC

Severity: normal

Tags: wontfix

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Yuan Fu <casouri <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70438 <at> debbugs.gnu.org, Stefan Heitmann <sh <at> bytekomplex.de>
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 <at> gnu.org> wrote:
> 
>> From: Yuan Fu <casouri <at> gmail.com>
>> Date: Sun, 21 Apr 2024 16:57:46 -0700
>> Cc: Stefan Heitmann <sh <at> bytekomplex.de>,
>> 70438 <at> 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



This bug report was last modified 1 year and 27 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.