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

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!

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?

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.