GNU bug report logs - #60842
29.0.50; Crash when printing sqlite object

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 60842 in the body.
You can then email your comments to 60842 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: Troy Hinckley <t.macman <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Crash when printing sqlite object
Date: Sun, 15 Jan 2023 16:38:52 -0700

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

I have run into a reproducible crash when trying to print a sqlite
object on Emacs 29. This is the code that will lead to the crash with
emacs -Q:

(prin1-to-string (sqlite-open
"/Users/troyhinckley/.emacs.d/var/org/org-roam.db"))

Iterestingly it will only happen when using something that matches that
path. Creating sqlite db anywhere else does not cause an issue. The path
passed to sqlite-open has to start with
/Users/troyhinckley/.emacs.d/var/org/org-roam

Will crash when printed:
/Users/troyhinckley/.emacs.d/var/org/org-roam.db
/Users/troyhinckley/.emacs.d/var/org/org-roams.db
/Users/troyhinckley/.emacs.d/var/org/org-roam-foo.db
/Users/troyhinckley/.emacs.d/var/org/org-roam.xz

Will not crash when printed:
/Users/troyhinckley/.emacs.d/var/org/org-roa.db
/Users/troyhinckley/.emacs.d/var/org-roam.db
/Users/troyhinckley/.emacs.d/var/org/org-roa

so it requires that prefix text. This happens even when I delete the db
at that path. Also it is not the sqlite-open that crashes. That works
fine. It is the call to prin1-to-string that crashes (you can see this
in the backtrace as well).

My best guess is that the sqlite library is caching some information
about different databases somewhere on the system, and that has become
corrupted, leading it to return something invalid when asked to print
the object. That would explain why only things starting with that path
will crash. I have no idea where that might be.



BACKTRACE:



(lldb) bt all
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
* frame #0: 0x00000001974ce1b0 libsystem_kernel.dylib`__pthread_kill + 8
frame #1: 0x0000000197504cec libsystem_pthread.dylib`pthread_kill + 288
frame #2: 0x000000019743e354 libsystem_c.dylib`__abort + 128
frame #3: 0x000000019742fd34 libsystem_c.dylib`__stack_chk_fail + 96
frame #4: 0x000000010476e528 Emacs`print_object + 5496
frame #5: 0x0000000104770308 Emacs`Fprin1_to_string + 132
frame #6: 0x000000010b9d77a0 elisp-mode-90dbfe40-11c86ede.eln`F656c6973702d2d6576616c2d6c6173742d736578702d7072696e742d76616c7565_elisp__eval_last_sexp_print_value_0 + 112
frame #7: 0x000000010474aa34 Emacs`Ffuncall + 316
frame #8: 0x000000010b9d7714 elisp-mode-90dbfe40-11c86ede.eln`F656c6973702d2d6576616c2d6c6173742d73657870_elisp__eval_last_sexp_0 + 368
frame #9: 0x000000010474aa34 Emacs`Ffuncall + 316
frame #10: 0x000000010b9d7bf0 elisp-mode-90dbfe40-11c86ede.eln`F6576616c2d6c6173742d73657870_eval_last_sexp_0 + 112
frame #11: 0x000000010474aa34 Emacs`Ffuncall + 316
frame #12: 0x0000000104747bc8 Emacs`Ffuncall_interactively + 68
frame #13: 0x000000010474aa34 Emacs`Ffuncall + 316
frame #14: 0x0000000104748c40 Emacs`Fcall_interactively + 4192
frame #15: 0x00000001090d55bc simple-fab5b0cf-76628045.eln`F636f6d6d616e642d65786563757465_command_execute_0 + 652
frame #16: 0x000000010474aa34 Emacs`Ffuncall + 316
frame #17: 0x00000001046d2268 Emacs`command_loop_1 + 1232
frame #18: 0x000000010474cd8c Emacs`internal_condition_case + 96
frame #19: 0x00000001046d1534 Emacs`command_loop_2 + 52
frame #20: 0x000000010474c7b0 Emacs`internal_catch + 88
frame #21: 0x000000010481487c Emacs`command_loop.cold.1 + 80
frame #22: 0x00000001046d1500 Emacs`command_loop + 152
frame #23: 0x00000001046d13bc Emacs`recursive_edit_1 + 148
frame #24: 0x00000001046d1960 Emacs`Frecursive_edit + 264
frame #25: 0x00000001046d099c Emacs`main + 7480
frame #26: 0x00000001971dbe50 dyld`start + 2544
thread #2
frame #0: 0x00000001974cbfa4 libsystem_kernel.dylib`__pselect + 8
frame #1: 0x00000001974cbe7c libsystem_kernel.dylib`pselect$DARWIN_EXTSN + 64
frame #2: 0x00000001047a7470 Emacs`process_output_producer_thread + 1380
frame #3: 0x000000019750506c libsystem_pthread.dylib`_pthread_start + 148
thread #3
frame #0: 0x00000001974cbfa4 libsystem_kernel.dylib`__pselect + 8
frame #1: 0x00000001974cbe7c libsystem_kernel.dylib`pselect$DARWIN_EXTSN + 64
frame #2: 0x00000001047a7590 Emacs`process_writer_thread + 268
frame #3: 0x000000019750506c libsystem_pthread.dylib`_pthread_start + 148
thread #4, name = 'gmain'
frame #0: 0x00000001974d0a00 libsystem_kernel.dylib`__select + 8
frame #1: 0x000000010588bb20 libglib-2.0.0.dylib`g_poll + 424
frame #2: 0x000000010587ecc4 libglib-2.0.0.dylib`g_main_context_iterate + 340
frame #3: 0x000000010587ed8c libglib-2.0.0.dylib`g_main_context_iteration + 60
frame #4: 0x0000000105880124 libglib-2.0.0.dylib`glib_worker_main + 48
frame #5: 0x00000001058a33a8 libglib-2.0.0.dylib`g_thread_proxy + 68
frame #6: 0x000000019750506c libsystem_pthread.dylib`_pthread_start + 148
thread #5
frame #0: 0x00000001974cbfa4 libsystem_kernel.dylib`__pselect + 8
frame #1: 0x00000001974cbe7c libsystem_kernel.dylib`pselect$DARWIN_EXTSN + 64
frame #2: 0x00000001047e0c30 Emacs`-[EmacsApp fd_handler:] + 184
frame #3: 0x00000001984e5470 Foundation`__NSThread__start__ + 716
frame #4: 0x000000019750506c libsystem_pthread.dylib`_pthread_start + 148
thread #6, name = 'com.apple.NSEventThread'
frame #0: 0x00000001974c5d70 libsystem_kernel.dylib`mach_msg2_trap + 8
frame #1: 0x00000001974d78a4 libsystem_kernel.dylib`mach_msg2_internal + 80
frame #2: 0x00000001974ce5c4 libsystem_kernel.dylib`mach_msg_overwrite + 540
frame #3: 0x00000001974c60ec libsystem_kernel.dylib`mach_msg + 24
frame #4: 0x00000001975e4bc0 CoreFoundation`__CFRunLoopServiceMachPort + 160
frame #5: 0x00000001975e34ac CoreFoundation`__CFRunLoopRun + 1232
frame #6: 0x00000001975e2888 CoreFoundation`CFRunLoopRunSpecific + 612
frame #7: 0x000000019a98e410 AppKit`_NSEventThread + 172
frame #8: 0x000000019750506c libsystem_pthread.dylib`_pthread_start + 148
thread #8
frame #0: 0x00000001974c7a1c libsystem_kernel.dylib`__workq_kernreturn + 8
thread #9
frame #0: 0x00000001974c7a1c libsystem_kernel.dylib`__workq_kernreturn + 8
thread #10
frame #0: 0x00000001974c7a1c libsystem_kernel.dylib`__workq_kernreturn + 8



LAST INSTRUCTIONS FROM DEBUGGER SESSION:

(lldb) n
Process 8086 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = instruction step over
frame #0: 0x00000001023a4304 Emacs`Fprin1_to_string + 128
Emacs`Fprin1_to_string:
-> 0x1023a4304 <+128>: bl 0x1023a0a20 ; print
0x1023a4308 <+132>: add x0, sp, #0x8
0x1023a430c <+136>: bl 0x10239fde4 ; print_finish
0x1023a4310 <+140>: ldr x8, [x24]
Target 0: (Emacs) stopped.
(lldb) n
Process 8086 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
frame #0: 0x00000001974ce1b0 libsystem_kernel.dylib`__pthread_kill + 8
libsystem_kernel.dylib`:
-> 0x1974ce1b0 <+8>: b.lo 0x1974ce1d0 ; <+40>
0x1974ce1b4 <+12>: pacibsp
0x1974ce1b8 <+16>: stp x29, x30, [sp, #-0x10]!
0x1974ce1bc <+20>: mov x29, sp
Target 0: (Emacs) stopped.
(lldb) n
Process 8086 exited with status = 6 (0x00000006) Terminated due to signal 6




In GNU Emacs 29.0.50 (build 1, aarch64-apple-darwin22.1.0, NS
appkit-2299.00 Version 13.0 (Build 22A380)) of 2022-12-05 built on
Troys-MacBook-Pro.local
Windowing system distributor 'Apple', version 10.3.2299
System Description: macOS 13.1

Configured using:
'configure --disable-dependency-tracking --disable-silent-rules
--enable-locallisppath=/opt/homebrew/share/emacs/site-lisp
--infodir=/opt/homebrew/Cellar/emacs-plus <at> 29/29.0.50/share/info/emacs
--prefix=/opt/homebrew/Cellar/emacs-plus <at> 29/29.0.50 --with-xml2
--with-gnutls --with-native-compilation --without-compress-install
--without-dbus --with-imagemagick --with-modules --with-rsvg
--with-xwidgets --with-ns --disable-ns-self-contained 'CFLAGS=-Os -w
-pipe -mmacosx-version-min=13
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk
-DFD_SETSIZE=10000 -DDARWIN_UNLIMITED_SELECT'
'CPPFLAGS=-I/opt/homebrew/opt/zlib/include
-I/opt/homebrew/opt/jpeg/include -I/opt/homebrew/opt/libomp/include
-I/opt/homebrew/opt/icu4c/include
-I/opt/homebrew/opt/openssl <at> 1.1/include
-I/opt/homebrew/opt/readline/include -isystem/opt/homebrew/include
-F/opt/homebrew/Frameworks
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk'
'LDFLAGS=-L/opt/homebrew/opt/zlib/lib -L/opt/homebrew/opt/jpeg/lib
-L/opt/homebrew/opt/libomp/lib -L/opt/homebrew/opt/icu4c/lib
-L/opt/homebrew/opt/openssl <at> 1.1/lib -L/opt/homebrew/opt/readline/lib
-L/opt/homebrew/lib -F/opt/homebrew/Frameworks
-Wl,-headerpad_max_install_names
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk''

Configured features:
ACL GIF GLIB GMP GNUTLS IMAGEMAGICK JPEG JSON LCMS2 LIBXML2 MODULES
NATIVE_COMP NOTIFY KQUEUE NS PDUMPER PNG RSVG SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS WEBP XIM XWIDGETS ZLIB

Important settings:
value of $LC_ALL: en_US.UTF-8
locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

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
indent-tabs-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 mail-extr emacsbug 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 mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
comp comp-cstr warnings icons subr-x rx cl-seq cl-macs gv cl-extra
help-mode bytecomp byte-compile cl-lib sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/ns-win ns-win ucs-normalize mule-util
term/common-win 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 xwidget-internal kqueue cocoa ns lcms2 multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 77340 8688)
(symbols 48 7009 0)
(strings 32 19124 2266)
(string-bytes 1 590662)
(vectors 16 16275)
(vector-slots 8 329701 12255)
(floats 8 27 46)
(intervals 56 305 0)
(buffers 984 10))

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Troy Hinckley <t.macman <at> gmail.com>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 60842 <at> debbugs.gnu.org
Subject: Re: bug#60842: 29.0.50; Crash when printing sqlite object
Date: Mon, 16 Jan 2023 15:16:12 +0200

> Date: Sun, 15 Jan 2023 16:38:52 -0700
> From: Troy Hinckley <t.macman <at> gmail.com>
> 
> I have run into a reproducible crash when trying to print a sqlite
> object on Emacs 29. This is the code that will lead to the crash with
> emacs -Q:
> 
> (prin1-to-string (sqlite-open
> "/Users/troyhinckley/.emacs.d/var/org/org-roam.db"))
> 
> Iterestingly it will only happen when using something that matches that
> path. Creating sqlite db anywhere else does not cause an issue. The path
> passed to sqlite-open has to start with
> /Users/troyhinckley/.emacs.d/var/org/org-roam
> 
> Will crash when printed:
> /Users/troyhinckley/.emacs.d/var/org/org-roam.db
> /Users/troyhinckley/.emacs.d/var/org/org-roams.db
> /Users/troyhinckley/.emacs.d/var/org/org-roam-foo.db
> /Users/troyhinckley/.emacs.d/var/org/org-roam.xz
> 
> Will not crash when printed:
> /Users/troyhinckley/.emacs.d/var/org/org-roa.db
> /Users/troyhinckley/.emacs.d/var/org-roam.db
> /Users/troyhinckley/.emacs.d/var/org/org-roa
> 
> so it requires that prefix text. This happens even when I delete the db
> at that path. Also it is not the sqlite-open that crashes. That works
> fine. It is the call to prin1-to-string that crashes (you can see this
> in the backtrace as well).
> 
> My best guess is that the sqlite library is caching some information
> about different databases somewhere on the system, and that has become
> corrupted, leading it to return something invalid when asked to print
> the object. That would explain why only things starting with that path
> will crash. I have no idea where that might be.
> 
> BACKTRACE:
> 
> (lldb) bt all
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
> * frame #0: 0x00000001974ce1b0 libsystem_kernel.dylib`__pthread_kill + 8
> frame #1: 0x0000000197504cec libsystem_pthread.dylib`pthread_kill + 288
> frame #2: 0x000000019743e354 libsystem_c.dylib`__abort + 128
> frame #3: 0x000000019742fd34 libsystem_c.dylib`__stack_chk_fail + 96
> frame #4: 0x000000010476e528 Emacs`print_object + 5496
> frame #5: 0x0000000104770308 Emacs`Fprin1_to_string + 132

Given that the abort is inside what sounds like the macOS run-time
stack-checking function, crystal ball says this is related to what
print_object does at the get-go:

  print_object (Lisp_Object obj, Lisp_Object printcharfun, bool escapeflag)
  {
    ptrdiff_t base_depth = print_depth;
    ptrdiff_t base_sp = prstack.sp;
    char buf[max (sizeof "from..to..in " + 2 * INT_STRLEN_BOUND (EMACS_INT),
		  max (sizeof " . #" + INT_STRLEN_BOUND (intmax_t),
		       max ((sizeof " with data 0x"
			     + (sizeof (uintmax_t) * CHAR_BIT + 4 - 1) / 4),
			    40)))];
    current_thread->stack_top = buf;  <<<<<<<<<<<<<<<<<<<<<<<<<<

If you remove the indicated line, does the crash go away?

If removing that line doesn't help, please tell the dimension of the
buf[] array that the code above calculates?  In GDB, this is possible
with the command 'ptype'; I don't know what is the lldb equivalent.

> In GNU Emacs 29.0.50 (build 1, aarch64-apple-darwin22.1.0, NS
> appkit-2299.00 Version 13.0 (Build 22A380)) of 2022-12-05 built on
> Troys-MacBook-Pro.local
> Windowing system distributor 'Apple', version 10.3.2299
> System Description: macOS 13.1

This is a month-old build -- could you try with the latest emacs-29
branch of the Emacs Git repository?

Paul, any ideas or suggestions?

Thanks.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, Troy Hinckley <t.macman <at> gmail.com>
Cc: 60842 <at> debbugs.gnu.org
Subject: Re: bug#60842: 29.0.50; Crash when printing sqlite object
Date: Tue, 17 Jan 2023 12:44:57 -0800

On 1/16/23 05:16, Eli Zaretskii wrote:

>      char buf[max (sizeof "from..to..in " + 2 * INT_STRLEN_BOUND (EMACS_INT),
> 		  max (sizeof " . #" + INT_STRLEN_BOUND (intmax_t),
> 		       max ((sizeof " with data 0x"
> 			     + (sizeof (uintmax_t) * CHAR_BIT + 4 - 1) / 4),
> 			    40)))];
>      current_thread->stack_top = buf;  <<<<<<<<<<<<<<<<<<<<<<<<<<
> 
> If you remove the indicated line, does the crash go away?
> 
> If removing that line doesn't help, please tell the dimension of the
> buf[] array that the code above calculates?  In GDB, this is possible
> with the command 'ptype'; I don't know what is the lldb equivalent.

sizeof buf should be 54 on his platform, which I assume has 64-bit 
addresses and 64-bit u?intmax_t.


> Paul, any ideas or suggestions?

Unfortunately not.

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

From: Troy Hinckley <t.macman <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 60842 <at> debbugs.gnu.org
Subject: Re: bug#60842: 29.0.50; Crash when printing sqlite object
Date: Sun, 29 Jan 2023 00:36:40 -0700

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

Sorry for the long delay. I updated my Emacs version to the latest 29 commit and the issue went away. I am no longer able to reproduce it. Thank you for the quick reply and debug though!
On Jan 17, 2023 at 1:44 PM -0700, Paul Eggert <eggert <at> cs.ucla.edu>, wrote:
> On 1/16/23 05:16, Eli Zaretskii wrote:
>
> > char buf[max (sizeof "from..to..in " + 2 * INT_STRLEN_BOUND (EMACS_INT),
> > max (sizeof " . #" + INT_STRLEN_BOUND (intmax_t),
> > max ((sizeof " with data 0x"
> > + (sizeof (uintmax_t) * CHAR_BIT + 4 - 1) / 4),
> > 40)))];
> > current_thread->stack_top = buf; <<<<<<<<<<<<<<<<<<<<<<<<<<
> >
> > If you remove the indicated line, does the crash go away?
> >
> > If removing that line doesn't help, please tell the dimension of the
> > buf[] array that the code above calculates? In GDB, this is possible
> > with the command 'ptype'; I don't know what is the lldb equivalent.
>
> sizeof buf should be 54 on his platform, which I assume has 64-bit
> addresses and 64-bit u?intmax_t.
>
>
> > Paul, any ideas or suggestions?
>
> Unfortunately not.
>

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Troy Hinckley <t.macman <at> gmail.com>
Cc: 60842-done <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#60842: 29.0.50; Crash when printing sqlite object
Date: Sun, 29 Jan 2023 09:55:04 +0200

> Date: Sun, 29 Jan 2023 00:36:40 -0700
> From: Troy Hinckley <t.macman <at> gmail.com>
> Cc: 60842 <at> debbugs.gnu.org
> 
> Sorry for the long delay. I updated my Emacs version to the latest 29 commit and the issue went away. I am
> no longer able to reproduce it. Thank you for the quick reply and debug though!

Thanks, I'm therefore closing the bug.

Previous Next

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