The latest trunk version of SQLite (c34fd9fe1b) and release version version-3.41.2 encounter Assertion Failures when executing the following query:

CREATE TABLE v0 (c1);
SELECT * FROM v0 WHERE base64 ( regexp_bytecode ( 'v304az' ) );

The Assertion Failure message is:

sqlite3: sqlite3.c:88559: void sqlite3_result_blob(sqlite3_context *, const void *, int, void (*)(void *)): Assertion `n>=0' failed.

Program received signal SIGABRT, Aborted.

Here is the stack trace(c34fd9fe1b):

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
        set = {__val = {0, 139849769064144, 2314885534501928960, 26894208, 26894309, 26894208, 26894208, 26894341, 26894508, 26894208, 26894508, 0, 0, 0, 0, 0}}
        pid = <optimized out>
        tid = <optimized out>
        ret = <optimized out>
#1  0x00007f314fc71859 in __GI_abort () at abort.c:79
        save_stage = 1
        act = {__sigaction_handler = {sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = {__val = {133, 4, 8616711968, 0, 0, 139849770218520, 0, 21474836480,
              140725601277216, 1, 139849770250256, 0, 12168680298156735232, 139849770218520, 139849773043712, 139849770235272}}, sa_flags = 8382624,
          sa_restorer = 0x159ef}
        sigs = {__val = {32, 0 <repeats 15 times>}}
#2  0x00007f314fc71729 in __assert_fail_base (fmt=0x7f314fe07588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x80a856 "n>=0", file=0x7fe8a0 "sqlite3.c",
    line=88559, function=<optimized out>) at assert.c:92
        str = 0x1a26ff0 "\260\037\233\001"
        total = 4096
#3  0x00007f314fc82fd6 in __GI___assert_fail (assertion=0x80a856 "n>=0", file=0x7fe8a0 "sqlite3.c", line=88559,
    function=0x7ff2e9 "void sqlite3_result_blob(sqlite3_context *, const void *, int, void (*)(void *))") at assert.c:101
No locals.
#4  0x000000000049da5a in sqlite3_result_blob (pCtx=<optimized out>, z=<optimized out>, n=<optimized out>, xDel=<optimized out>) at sqlite3.c:88559
No locals.
#5  0x0000000000407705 in base64 (context=0x1998fb0, na=<optimized out>, av=<optimized out>) at shell.c:3500
        nv = <optimized out>
        nvMax = <optimized out>
        nc = <optimized out>
        nb = 0
        cBuf = <optimized out>
        bBuf = 0x19af520 " \322\023\357\255\367\337M\370\353^\332"
#6  0x000000000054d790 in sqlite3VdbeExec (p=<optimized out>) at sqlite3.c:99083
        pCtx = 0x1998fb0
        i = <optimized out>
        azType = {0x818fd6 "NOT NULL", 0x819362 "UNIQUE", 0x80b0a9 "CHECK", 0x80b0af "FOREIGN KEY"}
        and_logic = "\000\000\000\000\001\002\000\002\002"
        or_logic = "\000\001\002\001\001\001\002\001\002"
        aMask = "\020\001\001\001\001\001\001\002\001\001\020\020"
        aFlag = {16, 514}
        vfsFlags = <optimized out>
        pOut = 0x1994df8
        pIn3 = <optimized out>
        pIn2 = <optimized out>
        pIn1 = <optimized out>
        resetSchemaOnFault = 0 '\000'
        aMem = 0x1994c00
        nVmStep = 14
        iCompare = 0
        encoding = <optimized out>
        db = <optimized out>
        rc = <optimized out>
        iCompareIsInit = 0 '\000'
        nExtraDelete = 0
        pOp = <optimized out>
        aOp = 0x19b3340
        nProgressLimit = 18446744073709551615
        pOrigOp = 0x19b3440
#7  0x000000000048ccfd in sqlite3Step (p=0x198ee40) at sqlite3.c:88874
        db = 0x1989150
        rc = <optimized out>
#8  sqlite3_step (pStmt=<optimized out>) at sqlite3.c:23399
        cnt = 0
        v = <optimized out>
        rc = <optimized out>
        db = 0x1989150
#9  0x0000000000472b1c in exec_prepared_stmt (pArg=0x7ffd3b79a6b8, pStmt=0x198ee40) at shell.c:19186
        nRow = 0
        rc = <optimized out>
#10 0x000000000043cc60 in shell_exec (pArg=<optimized out>, zSql=0x19a3190 "SELECT ALL * FROM ( v4 AS a43 ) WHERE base64 ( regexp_bytecode ( 'v304az' ) ) GROUP BY 1; ",
    pzErrMsg=<optimized out>) at shell.c:19503
        zStmtSql = 0x1998930 "SELECT ALL * FROM ( v4 AS a43 ) WHERE base64 ( regexp_bytecode ( 'v304az' ) ) GROUP BY 1;"
        pStmt = 0x7ffd3b7993b0
        rc = 0
        db = 0x1989150
        zLeftover = 0x19a31e9 " "
        rc2 = <optimized out>
#11 0x00000000004776c7 in runOneSqlLine (p=0x7ffd3b79a6b8, zSql=0x19a3190 "SELECT ALL * FROM ( v4 AS a43 ) WHERE base64 ( regexp_bytecode ( 'v304az' ) ) GROUP BY 1; ",
    in=0x7f314fe3b980 <_IO_2_1_stdin_>, startline=147) at shell.c:26568
        zErrMsg = 0x0
        rc = <optimized out>
#12 0x0000000000440e40 in process_input (p=<optimized out>) at shell.c:26734
        qss = QSS_ScanMask
        startline = 147
        errCnt = <optimized out>
        nAlloc = 250
        nSql = <optimized out>
        zSql = 0x19a3190 "SELECT ALL * FROM ( v4 AS a43 ) WHERE base64 ( regexp_bytecode ( 'v304az' ) ) GROUP BY 1; "
        zLine = <optimized out>
        rc = <optimized out>
        nLine = <optimized out>
#13 0x000000000041cecb in main (argc=<optimized out>, argv=0x7ffd3b79bce8) at shell.c:27675
        data = {db = 0x1989150, autoExplain = 1 '\001', autoEQP = 0 '\000', autoEQPtest = 0 '\000', autoEQPtrace = 0 '\000', scanstatsOn = 0 '\000', openMode = 1 '\001',
          doXdgOpen = 0 '\000', nEqpLevel = 0 '\000', eTraceType = 0 '\000', bSafeMode = 0 '\000', bSafeModePersist = 0 '\000', cmOpts = {iWrap = 0, bQuote = 0 '\000',
            bWordWrap = 0 '\000'}, statsOn = 0, mEqpLines = 0, inputNesting = 1, outCount = 0, cnt = 0, lineno = 147, openFlags = 0,
          in = 0x7f314fe3b980 <_IO_2_1_stdin_>, out = 0x7f314fe3c6a0 <_IO_2_1_stdout_>, traceOut = 0x0, nErr = 0, mode = 2, modePrior = 0, cMode = 2, normalMode = 2,
          writableSchema = 0, showHeader = 0, nCheck = 0, nProgress = 0, mxProgress = 0, flgProgress = 0, shellFlgs = 2, priorShFlgs = 0, szMax = 0, 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 = 0,
          nullValue = '\000' <repeats 19 times>, outfile = '\000' <repeats 4095 times>, pStmt = 0x198ee40, pLog = 0x0, aAuxDb = {{db = 0x0,
              zDbFilename = 0x7ddfd1 ":memory:", zFreeOnClose = 0x0, nSession = 0, aSession = {{zName = 0x0, nFilter = 0, azFilter = 0x0, p = 0x0}, {zName = 0x0,
                  nFilter = 0, azFilter = 0x0, p = 0x0}, {zName = 0x0, nFilter = 0, azFilter = 0x0, p = 0x0}, {zName = 0x0, nFilter = 0, azFilter = 0x0, p = 0x0}}}, {
              db = 0x0, zDbFilename = 0x0, zFreeOnClose = 0x0, nSession = 0, aSession = {{zName = 0x0, nFilter = 0, azFilter = 0x0, p = 0x0}, {zName = 0x0, nFilter = 0,
                  azFilter = 0x0, p = 0x0}, {zName = 0x0, nFilter = 0, azFilter = 0x0, p = 0x0}, {zName = 0x0, nFilter = 0, azFilter = 0x0, p = 0x0}}}, {db = 0x0,
              zDbFilename = 0x0, zFreeOnClose = 0x0, nSession = 0, aSession = {{zName = 0x0, nFilter = 0, azFilter = 0x0, p = 0x0}, {zName = 0x0, nFilter = 0,
                  azFilter = 0x0, p = 0x0}, {zName = 0x0, nFilter = 0, azFilter = 0x0, p = 0x0}, {zName = 0x0, nFilter = 0, azFilter = 0x0, p = 0x0}}}, {db = 0x0,
              zDbFilename = 0x0, zFreeOnClose = 0x0, nSession = 0, aSession = {{zName = 0x0, nFilter = 0, azFilter = 0x0, p = 0x0}, {zName = 0x0, nFilter = 0,
                  azFilter = 0x0, p = 0x0}, {zName = 0x0, nFilter = 0, azFilter = 0x0, p = 0x0}, {zName = 0x0, nFilter = 0, azFilter = 0x0, p = 0x0}}}, {db = 0x0,
              zDbFilename = 0x0, zFreeOnClose = 0x0, nSession = 0, aSession = {{zName = 0x0, nFilter = 0, azFilter = 0x0, p = 0x0}, {zName = 0x0, nFilter = 0,
                  azFilter = 0x0, p = 0x0}, {zName = 0x0, nFilter = 0, azFilter = 0x0, p = 0x0}, {zName = 0x0, nFilter = 0, azFilter = 0x0, p = 0x0}}}},
          pAuxDb = 0x7ffd3b79b800, aiIndent = 0x0, nIndent = 0, iIndent = 0, zNonce = 0x0, sGraph = {pRow = 0x0, pLast = 0x0, zPrefix = '\000' <repeats 99 times>},
          expert = {pExpert = 0x0, bVerbose = 0}}
        zErrMsg = <optimized out>
        mem_main_enter = 0
        zVfs = <optimized out>
        azCmd = 0x0
        nOptsEnd = 1
        nCmd = 0
        readStdin = 1338581003
        warnInmemoryDb = 1
        rc = 0
        zInitFile = <optimized out>
        i = <optimized out>

Here is the compilation option I used. The bug seems only reproducible when compiling with afl-clang-fast.

CC=afl-clang-fast ./configure --enable-debug --enable-all
make

In addition, the afl-clang-fast version is:

afl-clang-fast 2.57b by <lszekeres@google.com>
clang version 10.0.0-4ubuntu1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

We are not sure whether the problem is related to the compiler or the sqlite code, because the assertion can only be reproduced with afl-clang-fast compiler.

Some additional context.

When I compile SQLite with ASAN, the PoC triggers Global Buffer Overflow:

From version 3.41.2:

=================================================================
==31071==ERROR: AddressSanitizer: global-buffer-overflow on address 0xaaaab3ce42df at pc 0xaaaab364ef80 bp 0xffffec804080 sp 0xffffec804090
READ of size 1 at 0xaaaab3ce42df thread T0
    #0 0xaaaab364ef7c in fromBase64 /Users/yuliang/Desktop/Projects/DBMSs/sqlite/shell.c:3265
    #1 0xaaaab364f574 in base64 /Users/yuliang/Desktop/Projects/DBMSs/sqlite/shell.c:3336
    #2 0xaaaab3851e7c in sqlite3VdbeExec /Users/yuliang/Desktop/Projects/DBMSs/sqlite/sqlite3.c:98675
    #3 0xaaaab3805f80 in sqlite3Step /Users/yuliang/Desktop/Projects/DBMSs/sqlite/sqlite3.c:88491
    #4 0xaaaab3806aec in sqlite3_step /Users/yuliang/Desktop/Projects/DBMSs/sqlite/sqlite3.c:88552
    #5 0xaaaab36a1340 in exec_prepared_stmt /Users/yuliang/Desktop/Projects/DBMSs/sqlite/shell.c:19011
    #6 0xaaaab36a3390 in shell_exec /Users/yuliang/Desktop/Projects/DBMSs/sqlite/shell.c:19328
    #7 0xaaaab36d2750 in runOneSqlLine /Users/yuliang/Desktop/Projects/DBMSs/sqlite/shell.c:26447
    #8 0xaaaab36d35f8 in process_input /Users/yuliang/Desktop/Projects/DBMSs/sqlite/shell.c:26613
    #9 0xaaaab36d760c in main /Users/yuliang/Desktop/Projects/DBMSs/sqlite/shell.c:27507
    #10 0xffff934b73f8 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #11 0xffff934b74c8 in __libc_start_main_impl ../csu/libc-start.c:392
    #12 0xaaaab3640eac in _start (/Users/yuliang/Desktop/Projects/DBMSs/sqlite/sqlite3+0xf0eac)

0xaaaab3ce42df is located 59 bytes to the right of global variable 'one' defined in 'shell.c:2052:25' (0xaaaab3ce42a0) of size 4
0xaaaab3ce42df is located 1 bytes to the left of global variable 'nboi' defined in 'shell.c:3257:24' (0xaaaab3ce42e0) of size 5
SUMMARY: AddressSanitizer: global-buffer-overflow /Users/yuliang/Desktop/Projects/DBMSs/sqlite/shell.c:3265 in fromBase64
Shadow bytes around the buggy address:
  0x15655679c800: 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9
  0x15655679c810: f9 f9 f9 f9 05 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x15655679c820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x15655679c830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x15655679c840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x15655679c850: 00 00 00 00 04 f9 f9 f9 f9 f9 f9[f9]05 f9 f9 f9
  0x15655679c860: f9 f9 f9 f9 06 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x15655679c870: 00 00 00 00 f9 f9 f9 f9 00 00 00 00 00 00 00 00
  0x15655679c880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x15655679c890: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
  0x15655679c8a0: 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==31071==ABORTING

From 122431d3a7:

=================================================================
==33459==ERROR: AddressSanitizer: global-buffer-overflow on address 0xaaaada9322df at pc 0xaaaada290074 bp 0xffffcd020990 sp 0xffffcd0209a0
READ of size 1 at 0xaaaada9322df thread T0
    #0 0xaaaada290070 in fromBase64 /Users/yuliang/Desktop/Projects/DBMSs/sqlite/shell.c:3428
    #1 0xaaaada290668 in base64 /Users/yuliang/Desktop/Projects/DBMSs/sqlite/shell.c:3499
    #2 0xaaaada49692c in sqlite3VdbeExec /Users/yuliang/Desktop/Projects/DBMSs/sqlite/sqlite3.c:99083
    #3 0xaaaada44a934 in sqlite3Step /Users/yuliang/Desktop/Projects/DBMSs/sqlite/sqlite3.c:88874
    #4 0xaaaada44b4a0 in sqlite3_step /Users/yuliang/Desktop/Projects/DBMSs/sqlite/sqlite3.c:88935
    #5 0xaaaada2e24e0 in exec_prepared_stmt /Users/yuliang/Desktop/Projects/DBMSs/sqlite/shell.c:19186
    #6 0xaaaada2e4530 in shell_exec /Users/yuliang/Desktop/Projects/DBMSs/sqlite/shell.c:19503
    #7 0xaaaada31353c in runOneSqlLine /Users/yuliang/Desktop/Projects/DBMSs/sqlite/shell.c:26568
    #8 0xaaaada3143e4 in process_input /Users/yuliang/Desktop/Projects/DBMSs/sqlite/shell.c:26734
    #9 0xaaaada3185e4 in main /Users/yuliang/Desktop/Projects/DBMSs/sqlite/shell.c:27675
    #10 0xffffba4973f8 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #11 0xffffba4974c8 in __libc_start_main_impl ../csu/libc-start.c:392
    #12 0xaaaada281f6c in _start (/Users/yuliang/Desktop/Projects/DBMSs/sqlite/sqlite3+0xf1f6c)

0xaaaada9322df is located 59 bytes to the right of global variable 'one' defined in 'shell.c:2214:25' (0xaaaada9322a0) of size 4
0xaaaada9322df is located 1 bytes to the left of global variable 'nboi' defined in 'shell.c:3420:24' (0xaaaada9322e0) of size 5
SUMMARY: AddressSanitizer: global-buffer-overflow /Users/yuliang/Desktop/Projects/DBMSs/sqlite/shell.c:3428 in fromBase64
Shadow bytes around the buggy address:
  0x15655b526400: 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9
  0x15655b526410: f9 f9 f9 f9 05 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x15655b526420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x15655b526430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x15655b526440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x15655b526450: 00 00 00 00 04 f9 f9 f9 f9 f9 f9[f9]05 f9 f9 f9
  0x15655b526460: f9 f9 f9 f9 06 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x15655b526470: 00 00 00 00 f9 f9 f9 f9 00 00 00 00 00 00 00 00
  0x15655b526480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x15655b526490: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
  0x15655b5264a0: 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==33459==ABORTING

After looking at the assert that failed in sqlite3_result_blob(), then looking at its caller on the stack dump you showed, I came to realize that the extension functions known as base64() and base85() rely on returns from sqlite3_value_blob() and sqlite3_value_text() which may represent an OOM condition sometimes. This was not handled correctly, which I believe did or could lead to the assert your test managed to hit.

This oversight has been remedied by this recent check-in.

I was unable to replicate the problem in the manner you described. (My later afl++ version caused a crash in Lemon while it built the parser.) So I am hoping that you can cherry-pick the above-mentioned change and retry your test.

Hi Larry.

I just tested the recent check-in version: e6f9c0b1. The problem still persist.

Here is the stack trace from gdb(e6f9c0b1):

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x0000fffff7c7aaac in __GI_abort () at abort.c:79
#2  0x0000fffff7c87490 in __assert_fail_base (fmt=0xfffff7d82738 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x8b3479 "n>=0",
    file=file@entry=0x8a74c0 "sqlite3.c", line=line@entry=88559,
    function=function@entry=0x8a7f1b "void sqlite3_result_blob(sqlite3_context *, const void *, int, void (*)(void *))") at assert.c:92
#3  0x0000fffff7c874f4 in __GI___assert_fail (assertion=0x8b3479 "n>=0", file=0x8a74c0 "sqlite3.c", line=88559,
    function=0x8a7f1b "void sqlite3_result_blob(sqlite3_context *, const void *, int, void (*)(void *))") at assert.c:101
#4  0x00000000004b8ed0 in sqlite3_result_blob (pCtx=<optimized out>, z=<optimized out>, n=<optimized out>, xDel=<optimized out>) at sqlite3.c:88559
#5  0x0000000000407cbc in base64 (context=0x921e00, na=<optimized out>, av=<optimized out>) at shell.c:3514
#6  0x0000000000589e88 in sqlite3VdbeExec (p=<optimized out>) at sqlite3.c:99083
#7  0x00000000004a44fc in sqlite3Step (p=0x91fe20) at sqlite3.c:88874
#8  sqlite3_step (pStmt=0x91fe20) at sqlite3.c:23399
#9  0x0000000000485474 in exec_prepared_stmt (pArg=<optimized out>, pStmt=0x91fe20) at shell.c:19214
#10 0x00000000004471dc in shell_exec (pArg=<optimized out>, zSql=0x9120e0 "SELECT * FROM v0 WHERE base64 ( regexp_bytecode ( 'v304az' ) );", pzErrMsg=<optimized out>)
    at shell.c:19531
#11 0x000000000048a87c in runOneSqlLine (p=0xffffffffdca0, zSql=0x9120e0 "SELECT * FROM v0 WHERE base64 ( regexp_bytecode ( 'v304az' ) );",
    in=0xfffff7dc88d0 <_IO_2_1_stdin_>, startline=2) at shell.c:26596
#12 0x000000000044bd88 in process_input (p=<optimized out>) at shell.c:26762
#13 0x000000000041fe70 in main (argc=<optimized out>, argv=<optimized out>) at shell.c:27703

A global-buffer-overflow error is also posted in link when compiled with ASAN.

On my end, when I compile SQLite3 with ASAN (with CFLAGS=-fsanitize=address), I can reliably trigger a global-buffer-overflow error. Is it possible that this global-buffer-overflow is related to the Assertion Failure?

This appears to be a somewhat different issue. It is fixed here. Oddly enough, I think due to alignment and other auto variable allocations, this never caused an address fault and the misread value was not used, which would yield an incorrect result.¹ These factors allowed this bug to lurk unnoticed for awhile.

1. ^{^} I do not excuse the bug here; I just note that getting the right answer does not imply absence of UB.

Hi Larry. Thank you for the explanation. I double checked the patch commit 8f637aae23 here, and the address fault is indeed gone. Thank you for the super quick patch!

The original Assertion Failure seems to be fixed in commit: ab3331f4 (at least I cannot reproduce the error with the exact same build environment now). Thank you for the quick fix!

The original Assertion Failure seems to be fixed in commit: ab3331f4

That commit includes the fix for that so-called "global-buffer-overflow".¹ This fact relates to:

You asked, in post #5, "Is it possible that this global-buffer-overflow is related to the Assertion Failure?"

That would be possible only if the text provided to base64() was a single newline. I did not see that happening with your input, "regexp_bytecode ( 'v304az' )". But it is curious that when you include the changes in both e6f9c0b1 and 8f637aae check-ins, that assertion vanishes.

I will explore this further.

1. ^{^} It's not very global, being a static, function-local object, but it is undoubtedly stored alongside other static initialized data.