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

Previous Next

Full log

View this message in rfc822 format

From: Andrew Hyatt <ahyatt <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58850 <at> debbugs.gnu.org
Subject: bug#58850: 29.0.50; sqlite crashes on error
Date: Tue, 1 Nov 2022 00:28:36 -0400

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

On Sun, Oct 30, 2022 at 2:35 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > 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.
>

Thanks for the advice.

Right now, I narrowed the problem down to the sqlite connection name
creation, since it is the printing of the sqlite object's name that causes
the crash.
The creation of the name is on sqlite.c line 269 (
https://git.savannah.gnu.org/cgit/emacs.git/tree/src/sqlite.c#n269).  I can
make the crash go away by substituting that line with my own filename:
name = build_string("/tmp/test.db");

But I don't know what might be wrong with the line there as written.  I'll
continue to investigate, but it's possible that someone with better
knowledge of the emacs internal idioms might spot the issue.

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

Previous Next

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