GNU bug report logs - #61896
30.0.50; Emacs crashes because of an invalid free

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 61896 in the body.
You can then email your comments to 61896 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; Emacs crashes because of an invalid free
Date: Wed, 01 Mar 2023 20:25:11 +0000

[Message part 1 (text/plain, inline)]

Emacs just crashes out of nowhere, e.g. after I open a my init file.

I have had this device for a while on a device of mine, that I couldn't
reproduce on my main workstation or using emacs -Q.  Apparently this
could be related to some faulty byte-code.

The best I could do to detect this issue was to build Emacs using
-fsanitize=address and I managed to reprodce the issue reliably by
invoking package-recompile-all.  I collected the following log:

[log.1 (text/plain, attachment)]

[Message part 3 (text/plain, inline)]

I ran the same command in batch mode, and now the issue appears to be
fixed.  This gives me no reassurance, as a few days ago the I had
temporary managed to acchive the same state and then Emacs crashed again
after rebuilding again.

In GNU Emacs 30.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version
 3.24.36, cairo version 1.16.0) of 2023-03-01 built on quetzal
Repository revision: 4b99015e15a23bd5cbec021d53ef9fcca25b2441
Repository branch: master
System Description: Debian GNU/Linux bookworm/sid

Configured using:
 'configure --with-pgtk 'CFLAGS=-O0 -ggdb3 -fsanitize=address''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB

Important settings:
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: ELisp/l

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort emacsbug mail-extr message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
cus-edit pp cus-start cus-load icons wid-edit misearch multi-isearch
vc-git diff-mode easy-mmode vc-dispatcher cl-loaddefs cl-lib rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win
term/common-win pgtk-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo gtk pgtk lcms2 multi-tty make-network-process
emacs)

Memory information:
((conses 16 65648 11383)
 (symbols 48 7380 0)
 (strings 32 19680 1617)
 (string-bytes 1 540967)
 (vectors 16 12795)
 (vector-slots 8 182734 13738)
 (floats 8 32 68)
 (intervals 56 625 8)
 (buffers 984 13))

Message #8 received at 61896 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philip Kaludercic <philipk <at> posteo.net>, Mattias Engdegård <mattiase <at> acm.org>
Cc: 61896 <at> debbugs.gnu.org
Subject: Re: bug#61896: 30.0.50; Emacs crashes because of an invalid free
Date: Thu, 02 Mar 2023 08:15:10 +0200

> From: Philip Kaludercic <philipk <at> posteo.net>
> Date: Wed, 01 Mar 2023 20:25:11 +0000
> 
> Emacs just crashes out of nowhere, e.g. after I open a my init file.

It would help if you could run Emacs under GDB and show the backtrace
from one of those crashes, including the Lisp backtrace (the
"xbacktrace" command defined on src/.gdbinit).

> I have had this device for a while on a device of mine, that I couldn't
> reproduce on my main workstation or using emacs -Q.  Apparently this
> could be related to some faulty byte-code.
> 
> The best I could do to detect this issue was to build Emacs using
> -fsanitize=address and I managed to reprodce the issue reliably by
> invoking package-recompile-all.  I collected the following log:

Byte-code saw quite a bit of changes on master.  Adding Mattias in
case he has some ideas.

Message #11 received at 61896 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 61896 <at> debbugs.gnu.org
Subject: Re: bug#61896: 30.0.50; Emacs crashes because of an invalid free
Date: Thu, 02 Mar 2023 08:53:54 +0000

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

>> From: Philip Kaludercic <philipk <at> posteo.net>
>> Date: Wed, 01 Mar 2023 20:25:11 +0000
>> 
>> Emacs just crashes out of nowhere, e.g. after I open a my init file.
>
> It would help if you could run Emacs under GDB and show the backtrace
> from one of those crashes, including the Lisp backtrace (the
> "xbacktrace" command defined on src/.gdbinit).

I tried debugging it using GDB, but didn't know about xbacktrace.  Sadly
I cannot reproduce the issue any more (at least for now).

>> I have had this device for a while on a device of mine, that I couldn't
>> reproduce on my main workstation or using emacs -Q.  Apparently this
>> could be related to some faulty byte-code.
>> 
>> The best I could do to detect this issue was to build Emacs using
>> -fsanitize=address and I managed to reprodce the issue reliably by
>> invoking package-recompile-all.  I collected the following log:
>
> Byte-code saw quite a bit of changes on master.  Adding Mattias in
> case he has some ideas.

From what I recall, the address being freed was on the stack.  How does
the byte-code interpreter behave when the input is broken?  Is there
some way of validating if the byte-code is "coherent"?  If I manually
modify the byte code and replace random bytes, is the interpreter
written to expect this kind of issue?

Message #14 received at 61896 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: mattiase <at> acm.org, 61896 <at> debbugs.gnu.org
Subject: Re: bug#61896: 30.0.50; Emacs crashes because of an invalid free
Date: Thu, 02 Mar 2023 11:41:05 +0200

> From: Philip Kaludercic <philipk <at> posteo.net>
> Cc: Mattias Engdegård <mattiase <at> acm.org>,
>   61896 <at> debbugs.gnu.org
> Date: Thu, 02 Mar 2023 08:53:54 +0000
> 
> >From what I recall, the address being freed was on the stack.  How does
> the byte-code interpreter behave when the input is broken?  Is there
> some way of validating if the byte-code is "coherent"?  If I manually
> modify the byte code and replace random bytes, is the interpreter
> written to expect this kind of issue?

Sorry, I don't understand the questions.  Maybe Mattias will.

My interpretation of this problem is that some corruption happened to
the specpdl stuff, which causes SAFE_FREE decide that some data should
be 'free'd when it was actually allocated off the stack.  The question
is how could that happen.

Message #17 received at 61896 <at> debbugs.gnu.org (full text, mbox):

From: Rah Guzar <rahguzar <at> zohomail.eu>
To: 61896 <at> debbugs.gnu.org
Cc: Philip Kaludercic <philipk <at> posteo.net>
Subject: Re: bug#61896: 30.0.50; Emacs crashes because of an invalid free
Date: Thu, 02 Mar 2023 11:30:40 +0100

I encountered something very similar today after updating emacs.
In my case the crash was caused by trying to read an email from mu4e,
which I have installed as a systems package.

Like you I could everything worked fine with `emacs -Q`. After adding,
mu4e to the load path, I could load it and read messages successfully.
But with my own configuration it crashed even after removing all mu4e
related settings from my config. Emacs crashed and I could see the
following on the terminal I launched it from

free(): invalid pointer
Fatal error 6: Aborted

along with a backtrace.

After finding this thread, I copied the mu4e lisp files to a directory
writable by me and byte compiled those. Adding this directory to load-path
has fixed my problem.

I think the distro provided elc files were compiled by Emacs 28
and I am using a build of emacs 29 and some incompatible change
recently caused this problem.

For now, my fix works but is there a good way to deal with possibly
incompatible bytecode in site-lisp directory?

Rah Guzar

Philip Kaludercic <philipk <at> posteo.net> writes:

> Emacs just crashes out of nowhere, e.g. after I open a my init file.
>
> I have had this device for a while on a device of mine, that I couldn't
> reproduce on my main workstation or using emacs -Q.  Apparently this
> could be related to some faulty byte-code.
>
> The best I could do to detect this issue was to build Emacs using
> -fsanitize=address and I managed to reprodce the issue reliably by
> invoking package-recompile-all.  I collected the following log:
>
>
>
> I ran the same command in batch mode, and now the issue appears to be
> fixed.  This gives me no reassurance, as a few days ago the I had
> temporary managed to acchive the same state and then Emacs crashed again
> after rebuilding again.
>
> In GNU Emacs 30.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version
>  3.24.36, cairo version 1.16.0) of 2023-03-01 built on quetzal
> Repository revision: 4b99015e15a23bd5cbec021d53ef9fcca25b2441
> Repository branch: master
> System Description: Debian GNU/Linux bookworm/sid
>
> Configured using:
>  'configure --with-pgtk 'CFLAGS=-O0 -ggdb3 -fsanitize=address''
>
> Configured features:
> ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
> JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY
> PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
> TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB
>
> Important settings:
>   value of $LC_MONETARY: en_US.UTF-8
>   value of $LC_NUMERIC: en_US.UTF-8
>   value of $LC_TIME: en_US.UTF-8
>   value of $LANG: en_US.UTF-8
>   value of $XMODIFIERS: @im=ibus
>   locale-coding-system: utf-8-unix
>
> Major mode: ELisp/l
>
> Minor modes in effect:
>   tooltip-mode: t
>   global-eldoc-mode: t
>   eldoc-mode: t
>   show-paren-mode: t
>   electric-indent-mode: t
>   mouse-wheel-mode: t
>   tool-bar-mode: t
>   menu-bar-mode: t
>   file-name-shadow-mode: t
>   global-font-lock-mode: t
>   font-lock-mode: t
>   blink-cursor-mode: t
>   line-number-mode: t
>   transient-mark-mode: t
>   auto-composition-mode: t
>   auto-encryption-mode: t
>   auto-compression-mode: t
>
> Load-path shadows:
> None found.
>
> Features:
> (shadow sort emacsbug mail-extr message mailcap yank-media puny dired
> dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
> epg-config gnus-util text-property-search time-date subr-x mm-decode
> mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
> sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
> cus-edit pp cus-start cus-load icons wid-edit misearch multi-isearch
> vc-git diff-mode easy-mmode vc-dispatcher cl-loaddefs cl-lib rmc
> iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
> vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win
> term/common-win pgtk-dnd tool-bar dnd fontset image regexp-opt fringe
> tabulated-list replace newcomment text-mode lisp-mode prog-mode register
> page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
> scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
> frame minibuffer nadvice seq simple cl-generic indonesian philippine
> cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
> korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
> european ethiopic indian cyrillic chinese composite emoji-zwj charscript
> charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
> cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
> files window text-properties overlay sha1 md5 base64 format env
> code-pages mule custom widget keymap hashtable-print-readable backquote
> threads dbusbind inotify dynamic-setting system-font-setting
> font-render-setting cairo gtk pgtk lcms2 multi-tty make-network-process
> emacs)
>
> Memory information:
> ((conses 16 65648 11383)
>  (symbols 48 7380 0)
>  (strings 32 19680 1617)
>  (string-bytes 1 540967)
>  (vectors 16 12795)
>  (vector-slots 8 182734 13738)
>  (floats 8 32 68)
>  (intervals 56 625 8)
>  (buffers 984 13))

Message #20 received at 61896 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Rah Guzar <rahguzar <at> zohomail.eu>
Cc: 61896 <at> debbugs.gnu.org
Subject: Re: bug#61896: 30.0.50; Emacs crashes because of an invalid free
Date: Thu, 02 Mar 2023 10:58:08 +0000

Rah Guzar <rahguzar <at> zohomail.eu> writes:

> I encountered something very similar today after updating emacs.
> In my case the crash was caused by trying to read an email from mu4e,
> which I have installed as a systems package.
>
> Like you I could everything worked fine with `emacs -Q`. After adding,
> mu4e to the load path, I could load it and read messages successfully.
> But with my own configuration it crashed even after removing all mu4e
> related settings from my config. Emacs crashed and I could see the
> following on the terminal I launched it from
>
> free(): invalid pointer
> Fatal error 6: Aborted
>
> along with a backtrace.

This was exactly the issue I had, though in my case the byte code was
not from a site directory.

Could you start Emacs using GDB print and run the xbacktrace command
that is defined in emacs.git's src/.gdbinit file (I believe this is best
done by starting GDB within the src directory)?

> After finding this thread, I copied the mu4e lisp files to a directory
> writable by me and byte compiled those. Adding this directory to load-path
> has fixed my problem.
>
> I think the distro provided elc files were compiled by Emacs 28
> and I am using a build of emacs 29 and some incompatible change
> recently caused this problem.
>
> For now, my fix works but is there a good way to deal with possibly
> incompatible bytecode in site-lisp directory?
>
> Rah Guzar
>
> Philip Kaludercic <philipk <at> posteo.net> writes:
>
>> Emacs just crashes out of nowhere, e.g. after I open a my init file.
>>
>> I have had this device for a while on a device of mine, that I couldn't
>> reproduce on my main workstation or using emacs -Q.  Apparently this
>> could be related to some faulty byte-code.
>>
>> The best I could do to detect this issue was to build Emacs using
>> -fsanitize=address and I managed to reprodce the issue reliably by
>> invoking package-recompile-all.  I collected the following log:
>>
>>
>>
>> I ran the same command in batch mode, and now the issue appears to be
>> fixed.  This gives me no reassurance, as a few days ago the I had
>> temporary managed to acchive the same state and then Emacs crashed again
>> after rebuilding again.
>>
>> In GNU Emacs 30.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version
>>  3.24.36, cairo version 1.16.0) of 2023-03-01 built on quetzal
>> Repository revision: 4b99015e15a23bd5cbec021d53ef9fcca25b2441
>> Repository branch: master
>> System Description: Debian GNU/Linux bookworm/sid
>>
>> Configured using:
>>  'configure --with-pgtk 'CFLAGS=-O0 -ggdb3 -fsanitize=address''
>>
>> Configured features:
>> ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
>> JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY
>> PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
>> TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB
>>
>> Important settings:
>>   value of $LC_MONETARY: en_US.UTF-8
>>   value of $LC_NUMERIC: en_US.UTF-8
>>   value of $LC_TIME: en_US.UTF-8
>>   value of $LANG: en_US.UTF-8
>>   value of $XMODIFIERS: @im=ibus
>>   locale-coding-system: utf-8-unix
>>
>> Major mode: ELisp/l
>>
>> Minor modes in effect:
>>   tooltip-mode: t
>>   global-eldoc-mode: t
>>   eldoc-mode: t
>>   show-paren-mode: t
>>   electric-indent-mode: t
>>   mouse-wheel-mode: t
>>   tool-bar-mode: t
>>   menu-bar-mode: t
>>   file-name-shadow-mode: t
>>   global-font-lock-mode: t
>>   font-lock-mode: t
>>   blink-cursor-mode: t
>>   line-number-mode: t
>>   transient-mark-mode: t
>>   auto-composition-mode: t
>>   auto-encryption-mode: t
>>   auto-compression-mode: t
>>
>> Load-path shadows:
>> None found.
>>
>> Features:
>> (shadow sort emacsbug mail-extr message mailcap yank-media puny dired
>> dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
>> epg-config gnus-util text-property-search time-date subr-x mm-decode
>> mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
>> sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
>> cus-edit pp cus-start cus-load icons wid-edit misearch multi-isearch
>> vc-git diff-mode easy-mmode vc-dispatcher cl-loaddefs cl-lib rmc
>> iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
>> vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win
>> term/common-win pgtk-dnd tool-bar dnd fontset image regexp-opt fringe
>> tabulated-list replace newcomment text-mode lisp-mode prog-mode register
>> page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
>> scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
>> frame minibuffer nadvice seq simple cl-generic indonesian philippine
>> cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
>> korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
>> european ethiopic indian cyrillic chinese composite emoji-zwj charscript
>> charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
>> cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
>> files window text-properties overlay sha1 md5 base64 format env
>> code-pages mule custom widget keymap hashtable-print-readable backquote
>> threads dbusbind inotify dynamic-setting system-font-setting
>> font-render-setting cairo gtk pgtk lcms2 multi-tty make-network-process
>> emacs)
>>
>> Memory information:
>> ((conses 16 65648 11383)
>>  (symbols 48 7380 0)
>>  (strings 32 19680 1617)
>>  (string-bytes 1 540967)
>>  (vectors 16 12795)
>>  (vector-slots 8 182734 13738)
>>  (floats 8 32 68)
>>  (intervals 56 625 8)
>>  (buffers 984 13))

Message #23 received at 61896 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 61896 <at> debbugs.gnu.org
Subject: Re: bug#61896: 30.0.50; Emacs crashes because of an invalid free
Date: Thu, 2 Mar 2023 13:20:03 +0100

2 mars 2023 kl. 09.53 skrev Philip Kaludercic <philipk <at> posteo.net>:

>> Byte-code saw quite a bit of changes on master.  Adding Mattias in
>> case he has some ideas.
> 
> From what I recall, the address being freed was on the stack.  How does
> the byte-code interpreter behave when the input is broken?  Is there
> some way of validating if the byte-code is "coherent"?  If I manually
> modify the byte code and replace random bytes, is the interpreter
> written to expect this kind of issue?

The very first thing is to make sure you don't have any lingering *.elc files generated during the period of incompatibility regarding `save-restriction`. That issue should have been resolved by now; let's not chase ghosts. The indication of a specpdl imbalance does point to this being a possible cause.

The byte-code interpreter normally assumes the code to be correct and performs few checks since every cycle counts here. There are some additional checks to be enabled: the general --enable-checking=all, and/or compiling with -DBYTE_CODE_SAFE=1 (or just adding

#define BYTE_CODE_SAFE 1

early in bytecode.c, which is what I tend to do).

These checks do not audit the specpdl balance directly but that would be something to add if you don't make further progress.

Message #26 received at 61896 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 61896 <at> debbugs.gnu.org
Subject: Re: bug#61896: 30.0.50; Emacs crashes because of an invalid free
Date: Thu, 2 Mar 2023 16:21:12 +0100

[Message part 1 (text/plain, inline)]

> These checks do not audit the specpdl balance directly but that would be something to add if you don't make further progress.

You could try this patch if you build with --enable-checking=all:

[bytecode-specpdl-depth-check.diff (application/octet-stream, attachment)]

Message #29 received at 61896 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Rah Guzar <rahguzar <at> zohomail.eu>, Eli Zaretskii <eliz <at> gnu.org>,
 61896 <at> debbugs.gnu.org
Subject: Re: bug#61896: 30.0.50; Emacs crashes because of an invalid free
Date: Thu, 02 Mar 2023 17:41:50 +0000

Mattias Engdegård <mattiase <at> acm.org> writes:

>> These checks do not audit the specpdl balance directly but that would be something to add if you don't make further progress.
>
> You could try this patch if you build with --enable-checking=all:

As I mentioned in my other response, I cannot reproduce the issue for
now.  Rah mentioned that he still has the files that caused the issue,
so perhaps he can help?

Message #32 received at 61896 <at> debbugs.gnu.org (full text, mbox):

From: Rah Guzar <rahguzar <at> zohomail.eu>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 61896 <at> debbugs.gnu.org
Subject: Re: bug#61896: 30.0.50; Emacs crashes because of an invalid free
Date: Fri, 03 Mar 2023 11:51:22 +0100

I have never used gdb before so I will need to figure that out. I am traveling
today so this will not happen before Monday or Tuesday. But I will try it
sometime next week.


Philip Kaludercic <philipk <at> posteo.net> writes:

> Rah Guzar <rahguzar <at> zohomail.eu> writes:
>
>> I encountered something very similar today after updating emacs.
>> In my case the crash was caused by trying to read an email from mu4e,
>> which I have installed as a systems package.
>>
>> Like you I could everything worked fine with `emacs -Q`. After adding,
>> mu4e to the load path, I could load it and read messages successfully.
>> But with my own configuration it crashed even after removing all mu4e
>> related settings from my config. Emacs crashed and I could see the
>> following on the terminal I launched it from
>>
>> free(): invalid pointer
>> Fatal error 6: Aborted
>>
>> along with a backtrace.
>
> This was exactly the issue I had, though in my case the byte code was
> not from a site directory.
>
> Could you start Emacs using GDB print and run the xbacktrace command
> that is defined in emacs.git's src/.gdbinit file (I believe this is best
> done by starting GDB within the src directory)?
>
>> After finding this thread, I copied the mu4e lisp files to a directory
>> writable by me and byte compiled those. Adding this directory to load-path
>> has fixed my problem.
>>
>> I think the distro provided elc files were compiled by Emacs 28
>> and I am using a build of emacs 29 and some incompatible change
>> recently caused this problem.
>>
>> For now, my fix works but is there a good way to deal with possibly
>> incompatible bytecode in site-lisp directory?
>>
>> Rah Guzar
>>
>> Philip Kaludercic <philipk <at> posteo.net> writes:
>>
>>> Emacs just crashes out of nowhere, e.g. after I open a my init file.
>>>
>>> I have had this device for a while on a device of mine, that I couldn't
>>> reproduce on my main workstation or using emacs -Q.  Apparently this
>>> could be related to some faulty byte-code.
>>>
>>> The best I could do to detect this issue was to build Emacs using
>>> -fsanitize=address and I managed to reprodce the issue reliably by
>>> invoking package-recompile-all.  I collected the following log:
>>>
>>>
>>>
>>> I ran the same command in batch mode, and now the issue appears to be
>>> fixed.  This gives me no reassurance, as a few days ago the I had
>>> temporary managed to acchive the same state and then Emacs crashed again
>>> after rebuilding again.
>>>
>>> In GNU Emacs 30.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version
>>>  3.24.36, cairo version 1.16.0) of 2023-03-01 built on quetzal
>>> Repository revision: 4b99015e15a23bd5cbec021d53ef9fcca25b2441
>>> Repository branch: master
>>> System Description: Debian GNU/Linux bookworm/sid
>>>
>>> Configured using:
>>>  'configure --with-pgtk 'CFLAGS=-O0 -ggdb3 -fsanitize=address''
>>>
>>> Configured features:
>>> ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
>>> JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY
>>> PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
>>> TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB
>>>
>>> Important settings:
>>>   value of $LC_MONETARY: en_US.UTF-8
>>>   value of $LC_NUMERIC: en_US.UTF-8
>>>   value of $LC_TIME: en_US.UTF-8
>>>   value of $LANG: en_US.UTF-8
>>>   value of $XMODIFIERS: @im=ibus
>>>   locale-coding-system: utf-8-unix
>>>
>>> Major mode: ELisp/l
>>>
>>> Minor modes in effect:
>>>   tooltip-mode: t
>>>   global-eldoc-mode: t
>>>   eldoc-mode: t
>>>   show-paren-mode: t
>>>   electric-indent-mode: t
>>>   mouse-wheel-mode: t
>>>   tool-bar-mode: t
>>>   menu-bar-mode: t
>>>   file-name-shadow-mode: t
>>>   global-font-lock-mode: t
>>>   font-lock-mode: t
>>>   blink-cursor-mode: t
>>>   line-number-mode: t
>>>   transient-mark-mode: t
>>>   auto-composition-mode: t
>>>   auto-encryption-mode: t
>>>   auto-compression-mode: t
>>>
>>> Load-path shadows:
>>> None found.
>>>
>>> Features:
>>> (shadow sort emacsbug mail-extr message mailcap yank-media puny dired
>>> dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
>>> epg-config gnus-util text-property-search time-date subr-x mm-decode
>>> mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
>>> sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
>>> cus-edit pp cus-start cus-load icons wid-edit misearch multi-isearch
>>> vc-git diff-mode easy-mmode vc-dispatcher cl-loaddefs cl-lib rmc
>>> iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
>>> vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win
>>> term/common-win pgtk-dnd tool-bar dnd fontset image regexp-opt fringe
>>> tabulated-list replace newcomment text-mode lisp-mode prog-mode register
>>> page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
>>> scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
>>> frame minibuffer nadvice seq simple cl-generic indonesian philippine
>>> cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
>>> korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
>>> european ethiopic indian cyrillic chinese composite emoji-zwj charscript
>>> charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
>>> cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
>>> files window text-properties overlay sha1 md5 base64 format env
>>> code-pages mule custom widget keymap hashtable-print-readable backquote
>>> threads dbusbind inotify dynamic-setting system-font-setting
>>> font-render-setting cairo gtk pgtk lcms2 multi-tty make-network-process
>>> emacs)
>>>
>>> Memory information:
>>> ((conses 16 65648 11383)
>>>  (symbols 48 7380 0)
>>>  (strings 32 19680 1617)
>>>  (string-bytes 1 540967)
>>>  (vectors 16 12795)
>>>  (vector-slots 8 182734 13738)
>>>  (floats 8 32 68)
>>>  (intervals 56 625 8)
>>>  (buffers 984 13))

Message #35 received at 61896 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Rah Guzar <rahguzar <at> zohomail.eu>
Cc: 61896 <at> debbugs.gnu.org
Subject: Re: bug#61896: 30.0.50; Emacs crashes because of an invalid free
Date: Fri, 03 Mar 2023 18:00:57 +0000

Rah Guzar <rahguzar <at> zohomail.eu> writes:

> I have never used gdb before so I will need to figure that out. I am traveling
> today so this will not happen before Monday or Tuesday. But I will try it
> sometime next week.

It shouldn't be that difficult, I usually first reconfigure Emacs with
debugging information:

   $ pwd
   /home/user/src/emacs/
   $ ./configure CFLAGS="-ggdb3"

Then all you need to do is to start Emacs in the src sub-directory using
GDB and then try to provoke the bug:

   $ pwd
   /home/user/src/emacs/src
   $ gdb emacs |& tee error.log
   ... # Copyright and stuff here.
   (gdb) run -Q
   ... # Emacs is running now and you can load the broken bytecode.
       # The next GDB prompt will appear when Emacs aborts.
   (gdb) xbacktrace
   ... # The Lisp backtrace should appear here.
   (gdb) quit
   
If you do this, then the entire session log should be store in the
"error.log" file.

-- 
Philip Kaludercic

Message #38 received at 61896 <at> debbugs.gnu.org (full text, mbox):

From: Rah Guzar <rahguzar <at> zohomail.eu>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 61896 <at> debbugs.gnu.org
Subject: Re: bug#61896: 30.0.50; Emacs crashes because of an invalid free
Date: Mon, 06 Mar 2023 20:52:50 +0100

Hi!
  I tried again today and I can no longer reproduce the bug with the bytecode
  in the site-lisp directory. The byte code hasn't been updated but my emacs
  was updated yesterday. I have also tried building emacs-29 from source and
  that also works fine. So it seems like the problem has been fixed.

Philip Kaludercic <philipk <at> posteo.net> writes:

> Rah Guzar <rahguzar <at> zohomail.eu> writes:
>
>> I have never used gdb before so I will need to figure that out. I am traveling
>> today so this will not happen before Monday or Tuesday. But I will try it
>> sometime next week.
>
> It shouldn't be that difficult, I usually first reconfigure Emacs with
> debugging information:
>
>    $ pwd
>    /home/user/src/emacs/
>    $ ./configure CFLAGS="-ggdb3"
>
> Then all you need to do is to start Emacs in the src sub-directory using
> GDB and then try to provoke the bug:
>
>    $ pwd
>    /home/user/src/emacs/src
>    $ gdb emacs |& tee error.log
>    ... # Copyright and stuff here.
>    (gdb) run -Q
>    ... # Emacs is running now and you can load the broken bytecode.
>        # The next GDB prompt will appear when Emacs aborts.
>    (gdb) xbacktrace
>    ... # The Lisp backtrace should appear here.
>    (gdb) quit
>
> If you do this, then the entire session log should be store in the
> "error.log" file.

Message #43 received at 61896-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Rah Guzar <rahguzar <at> zohomail.eu>
Cc: 61896-done <at> debbugs.gnu.org, Philip Kaludercic <philipk <at> posteo.net>
Subject: Re: bug#61896: 30.0.50; Emacs crashes because of an invalid free
Date: Tue, 5 Sep 2023 17:02:36 -0700

Rah Guzar <rahguzar <at> zohomail.eu> writes:

> Hi!
>   I tried again today and I can no longer reproduce the bug with the bytecode
>   in the site-lisp directory. The byte code hasn't been updated but my emacs
>   was updated yesterday. I have also tried building emacs-29 from source and
>   that also works fine. So it seems like the problem has been fixed.

Thanks, I'm therefore closing this bug report.

Previous Next

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