GNU bug report logs - #58850
29.0.50; sqlite crashes on error

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrew Hyatt <ahyatt <at> gmail.com>
Cc: 58850 <at> debbugs.gnu.org
Subject: bug#58850: 29.0.50; sqlite crashes on error
Date: Sun, 30 Oct 2022 08:35:03 +0200

> From: Andrew Hyatt <ahyatt <at> gmail.com>
> Date: Sat, 29 Oct 2022 19:44:17 -0400
> Cc: 58850 <at> debbugs.gnu.org
> 
>  > Some combination of sqlite and getting errors that result in backtraces
>  > seems to result in a problem.
>  > 
>  > Relevant information from the crash report:
>  > Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
>  > 0   libsystem_kernel.dylib                   0x1aab6ed98 __pthread_kill + 8
>  > 1   libsystem_pthread.dylib                  0x1aaba3ee0 pthread_kill + 288
>  > 2   libsystem_c.dylib                        0x1aaade3cc __abort + 128
>  > 3   libsystem_c.dylib                        0x1aaacfd48 __stack_chk_fail + 96
>  > 4   Emacs                                    0x102dcdbd8 print_object + 5920
>  > 5   Emacs                                    0x102dc9d50 Fprin1 + 112 (print.c:775)
> 
>  Please try the latest master branch.  Jonas installed changes there
>  that are related to sqlite error handling, and with today's master I
>  get a Lisp error with your recipe, not a crash:
> 
>    Debugger entered--Lisp error: (sqlite-error ("SQL logic error" "no such table: bar" 1 1))
> 
> I've synced, rebuilt, verified Jonas's change is there, however the crash still occurs. 

Then please walk through the code with a debugger and tell us what
kind of object is being created as result of the error that Emacs
cannot print via prin1 because print_object barfs.  I cannot do it
here because the problem doesn't happen on my system in the first
place.

The way to fix this is one of the following, whichever seems cleaner:

  . repair the object before it gets to the printing routines,
    preferably where it is created; or
  . add some protection to routines in print.c to stop short of trying
    to look too closely at invalid Lisp objects

Only debugging can tell which way is the best one here, but all things
being equal, I'd prefer the former.

Previous Next

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