bug#60842: 29.0.50; Crash when printing sqlite object

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 15 Jan 2023 16:38:52 -0700
> From: Troy Hinckley <t.macman@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.