In Windows it gives 'Error: out of memory' and aborts with just 'PRAGMA hard_heap_limit=1;'

 8:53:10.54>sqlite3
-- Loading resources from C:\Users\jicman/.sqliterc
SQLite version 3.39.4 2022-09-29 15:55:41
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> PRAGMA hard_heap_limit=1;
Error: out of memory

 8:53:31.85>

FYI.

I had the same result on macOS Monterey on an M1:

2022-10-31 13:39:46
~/MyDB trudge: sqlite
-- Loading resources from /Users/trudge/.sqliterc
SQLite version 3.38.2 2022-03-26 13:51:10
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> PRAGMA hard_heap_limit=1;
Error: out of memory
2022-10-31 13:40:18
~/MyDB trudge: 

FWIW the sqlite online wasm fiddle has similar characteristics when executing:

PRAGMA hard_heap_limit=1;

"Similar" in the sense that you cannot recreate the behavior observed by Yu Liang? Nor has anybody else. But I did check-in a change (cb12ac5de17e677f) that should address the issue, if his stack trace is correct.

This is fiddle's result:

SQLite version 3.40.0 2022-10-26 15:40:17
Welcome to the "fiddle" shell.

Enter ".help" for usage hints.
.nullvalue NULL
.headers on
Resetting database.
Reset 
Error: out of memory
FATAL ERROR: Program terminated with exit(1)
Restarting the app requires reloading the page.

And on the top of the screen one gets,

Exception thrown, see JavaScript console: [object Object]

I hope this helps.

josé

Yes. When an out-of-memory (OOM) error is seen, the usual behavior of the CLI is to invoke exit(). That is what you are seeing here. The bug report from Yu Liang is that instead of calling exit(), the code is trying to dereference a NULL pointer. That is a very different matter. I have not seen any reproduction of the code dereferencing a NULL pointer. Nevertheless, the CLI source code has been updated to guard against this, based on the stack trace provided by Yu Liang.

Hi Richard, after applying patch d6893183, the NULL pointer dereference problem is also gone on our side. We believe the bug is fixed.

Some additional debug information when triggering the crash in version: 7660db2a2e: We are using x86-64 Ubuntu 20.04 LTS operating system. And the compiler we used is gcc-9 (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0. The configure command we used is shown below:

CC=gcc-9 ./configure --enable-debug

And the command we used to crash the application is:

./sqlite3 < poc

where the poc file holds the PoC query:

PRAGMA hard_heap_limit=1
0

Here is the full backtrace from gdb:

#0  0x000055555558afa1 in shell_error_context (zSql=0x555555794ef0 "PRAGMA hard_heap_limit=1\n0", db=0x55555578da20) at shell.c:17008
        iOffset = 0x19
        len = 0x1a
        zCode = 0x0
        zMsg = 0x7fffffffc4d0 "P\305\377\377\377\177"
        i = 0x0
#1  0x000055555558b322 in save_err_msg (db=0x55555578da20, zPhase=0x5555557130fd "in prepare", rc=0x1, zSql=0x555555794ef0 "PRAGMA hard_heap_limit=1\n0") at shell.c:17088
        zErr = 0x155586759 <error: Cannot access memory at address 0x155586759>
        zContext = 0x0
        pStr = 0x555555785260 <sqlite3OomStr>
#2  0x000055555558f079 in shell_exec (pArg=0x7fffffffceb0, zSql=0x555555794ef0 "PRAGMA hard_heap_limit=1\n0", pzErrMsg=0x7fffffffc588) at shell.c:18236
        zStmtSql = 0x0
        pStmt = 0x0
        rc = 0x1
        rc2 = 0x0
        zLeftover = 0x555555794f0a ""
        db = 0x55555578da20
#3  0x00005555555a3012 in runOneSqlLine (p=0x7fffffffceb0, zSql=0x555555794ef0 "PRAGMA hard_heap_limit=1\n0", in=0x7ffff7dc8980 <_IO_2_1_stdin_>, startline=0x1)
    at shell.c:25330
        rc = 0x5555
        zErrMsg = 0x0
#4  0x00005555555a37e4 in process_input (p=0x7fffffffceb0) at shell.c:25513
        zLine = 0x0
        zSql = 0x555555794ef0 "PRAGMA hard_heap_limit=1\n0"
        nLine = 0x1
        nSql = 0x1a
        nAlloc = 0x7c
        rc = 0x0
        errCnt = 0x0
        startline = 0x1
        qss = QSS_HasDark
        __PRETTY_FUNCTION__ = "process_input"
#5  0x00005555555a5914 in main (argc=0x1, argv=0x7fffffffe228) at shell.c:26349
        mem_main_enter = 0x0
        zErrMsg = 0x0
        data = {
          db = 0x55555578da20,
          autoExplain = 0x1,
          autoEQP = 0x0,
          autoEQPtest = 0x0,
          autoEQPtrace = 0x0,
          scanstatsOn = 0x0,
          openMode = 0x1,
          doXdgOpen = 0x0,
          nEqpLevel = 0x0,
          eTraceType = 0x0,
          bSafeMode = 0x0,
          bSafeModePersist = 0x0,
          cmOpts = {
            iWrap = 0x0,
            bQuote = 0x0,
            bWordWrap = 0x0
          },
          statsOn = 0x0,
          mEqpLines = 0x0,
          inputNesting = 0x1,
          outCount = 0x0,
          cnt = 0x0,
          lineno = 0x2,
          openFlags = 0x0,
          in = 0x7ffff7dc8980 <_IO_2_1_stdin_>,
          out = 0x7ffff7dc96a0 <_IO_2_1_stdout_>,
          traceOut = 0x0,
          nErr = 0x0,
          mode = 0x2,
          modePrior = 0x0,
          cMode = 0x2,
          normalMode = 0x2,
          writableSchema = 0x0,
          showHeader = 0x0,
          nCheck = 0x0,
          nProgress = 0x0,
          mxProgress = 0x0,
          flgProgress = 0x0,
          shellFlgs = 0x2,
          priorShFlgs = 0x0,
          szMax = 0x0,
          zDestTable = 0x0,
          zTempFile = 0x0,
          zTestcase = '\000' <repeats 29 times>,
          colSeparator = "|", '\000' <repeats 18 times>,
          rowSeparator = "\n", '\000' <repeats 18 times>,
          colSepPrior = '\000' <repeats 19 times>,
          rowSepPrior = '\000' <repeats 19 times>,
          colWidth = 0x0,
          actualWidth = 0x0,
          nWidth = 0x0,
          nullValue = '\000' <repeats 19 times>,
          outfile = '\000' <repeats 4095 times>,
          pStmt = 0x0,
          pLog = 0x0,
          aAuxDb = {{
              db = 0x0,
              zDbFilename = 0x555555710963 ":memory:",
              zFreeOnClose = 0x0
            }, {
              db = 0x0,
              zDbFilename = 0x0,
              zFreeOnClose = 0x0
            }, {
              db = 0x0,
              zDbFilename = 0x0,
              zFreeOnClose = 0x0
            }, {
              db = 0x0,
              zDbFilename = 0x0,
              zFreeOnClose = 0x0
            }, {
              db = 0x0,
              zDbFilename = 0x0,
              zFreeOnClose = 0x0
            }},
          pAuxDb = 0x7fffffffdff8,
          aiIndent = 0x0,
          nIndent = 0x0,
          iIndent = 0x0,
          zNonce = 0x0,
          sGraph = {
            pRow = 0x0,
            pLast = 0x0,
            zPrefix = '\000' <repeats 99 times>
          },
          expert = {
            pExpert = 0x0,
            bVerbose = 0x0
          }
        }
        zInitFile = 0x0
        i = 0x1
        rc = 0x0
        warnInmemoryDb = 0x1
        readStdin = 0x1
        nCmd = 0x0
        azCmd = 0x0
        zVfs = 0x0
        __PRETTY_FUNCTION__ = "main"
#6  0x00007ffff7c00083 in __libc_start_main (main=0x5555555a3d60 <main>, argc=0x1, argv=0x7fffffffe228, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7fffffffe218) at ../csu/libc-start.c:308
        self = <optimized out>
        result = <optimized out>
        unwind_buf = {
          cancel_jmp_buf = {{
              jmp_buf = {0x55555570e3b0, 0x57da55cf80eeb113, 0x555555568ea0, 0x7fffffffe220, 0x0, 0x0, 0xa825aa30426eb113, 0xa825ba4f8080b113},
              mask_was_saved = 0x0
            }},
          priv = {
            pad = {0x0, 0x0, 0x1, 0x7fffffffe228},
            data = {
              prev = 0x0,
              cleanup = 0x0,
              canceltype = 0x1
            }
          }
        }
        not_first_call = <optimized out>
#7  0x0000555555568ece in _start ()
No symbol table info available.

Anyway, we appreciate the quick bug fix and the fast reply. Thank you!

Sorry for the delayed response (was out for the day). This post is just to clear up your question, although it appears moot at this point.

Yes, similar to Jose's example (I could have made that more clear, my apologies) and that it did not recreate Yu's behavior.

My intent was to note that jose's example was similar in the wasm fiddle.

regards

I was able to reproduce this in VS2019 on Windows with a very similar stack trace.

Not sure if this was obvious or not or maybe I'm missing something... but the trick to reproduce is to run the query from a file as defined by the OP:

PRAGMA hard_heap_limit=1
0

Running just the PRAGMA in the CLA is not the same as it is missing the extra 0. Not sure if the OP meant to have that 0 in his query file...