bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#58850: 29.0.50; sqlite crashes on error


From: Andrew Hyatt
Subject: bug#58850: 29.0.50; sqlite crashes on error
Date: Tue, 1 Nov 2022 00:28:36 -0400

On Sun, Oct 30, 2022 at 2:35 AM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Andrew Hyatt <ahyatt@gmail.com>
> Date: Sat, 29 Oct 2022 19:44:17 -0400
> Cc: 58850@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.

 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]