Everything works fine (including under valgrind, and various -fsanitize= options) on every other platform we've tried, including systems running on unusual CPUs like PPC and RISC-V. This must be something specific to SunOS and/or Sparc.

Are you able to provide the SQLite developers with an SSH login to a SunOS-Sparc machine so that we can debug it?

yes we can provide login

Thank you, Marcel, for the SSH access.

I am unable to reproduce the problem using my own builds of SQLite from sources. I don't have read permission on the /var/opt/jomasoft/vdcf/db/infra.db database, so I cannot test with that. But using other databases, SQLite seems to work just fine. The compiler does give lots of warnings of like this:

warning: array subscript has type 'char'

That's a warning I've never seen before, and which I don't really understand. Is there some issue using a char value as a subscription on Sparc or something? Why do we not see that warning on other platforms?

I'm running "gmail test" on version 3.50.3 on your machine as I type in this response. No issues detected so far...

How are you building SQLite?

Could it be related to the signed'ness of char?

I read that for this compiler, on SPARC it's unsigned and on Intel/AMD it's signed.
Which platform are you compiling for? (sounded like the former, i.e. SPARC).
Do you have an (GCC style) option like -fsigned-char to force it, for that compiler?

We routinely run 100% MC/DC tests in TH3 using both -fsigned-char and -funsigned-char on both Intel and ARM platforms. So SQLite should work the same regardless of whether characters are natively signed or unsigned.

SIGBUS generally means an alignment issue.

With the cooperation of the OP, we have access to the Sparc machine that demonstrates the problem and what we have found is that SQLite works fine when compiled on that machine using GCC. It only shows the SIGBUS when compiled using the DeveloperStudio 12.6 compiler. We were able to bisect back to the introduction of the Flexible Array syntax by check-in 2025-03-15T19:55z as recommended by forum post 2025-03-13T15:50:54z.

Thanks for the update. Wikipedia does state:

Flexible array members were officially standardized in C99.
In practice, compilers (e.g. GCC, MSVC) provided them well before C99 was standardized.

I thought SQLite stuck to C89 (aka ANSI C).

Different compiler, different non-standard extensions (or lack thereof).

Perhaps there's an option to opt-in to C99 for that compiler? Might compile as-is then?

Perhaps there's an option to opt-in to C99 for that compiler?

That's a great suggestion. That compiler claims to support -std=c99. Trying...

Nope. Same crash.

Also tried with -std=c11 and -std=gnu11, both of which it claims to support.

Might compile as-is then?

It's compiling fine, barring a mountain of warnings about "empty declarations" and "unreachable statements" which we don't otherwise see, but it really doesn't like the flex-array thing.

Edit:

I thought SQLite stuck to C89 (aka ANSI C).

For the most part, yes, but some features require inching outside of that box. A prominent example is the long long type, which is not part of C89 but which is implemented by every known extant compiler.

In src/resolve.c, function sqlite3ResolveSelfReference, before this commit:

  SrcList sSrc;                   /* Fake SrcList for pParse->pNewTable */

and after this commit:

  SrcList *pSrc;                  /* Fake SrcList for pParse->pNewTable */
  u8 srcSpace[SZ_SRCLIST_1];     /* Memory space for the fake SrcList */
  pSrc = (SrcList*)srcSpace;

This is alignment error bait.

To ensure correct alignment, try using a union:

  union {
    SrcList sSrc;                   /* Fake SrcList for pParse->pNewTable */
    u8 space[SZ_SRCLIST_1];
  } uSrc;

There are similar constructs in these files:

src/trigger.c
src/vdbeInt.h
src/wherecode.c
ext/fts5/fts5_index.c
test/fuzzcheck.c

I started working on that, but then I discovered that check-in 2025-07-30T18:23:33z which cases the SQLITE_PTRSIZE macro to be set to 4 instead of 8 for the Developer-Studio compiler is sufficient to clear the problem. One can also work-around the problem by compile with CFLAGS=-DSQLITE_PTRSIZE=4.

I spoke too soon. Apparently I was compiling without the -m64 flag, and without that flag, no changes are needed. I have to add Bo's patch (or similar) to get it to work with the -m64 flag on the compiler....

Stephan implemented Bo's alignment suggestion and that seems to clear the problem regardless of the presence or absence of the -m64 flag. Those changes are now on trunk. So I think the issue is now resolved.

I've also seen SIGBUS when an active process's executable file lives on NFS, and the file is replaced while the process is running.

Indeed, but we're talking about SPARC, and the scenario you describe didn't seem likely here ;)

But you are of course right. I was just trying to describe what looks likely here (i.e. alignment) and that signedness of char was surely a red herring.