https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120837
Bug ID: 120837
Summary: False-positive from -fsanitize=undefined
Product: gcc
Version: 13.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: drh at sqlite dot org
Target Milestone: ---
UBSAN is raising an error on what appears to be perfectly valid code. The
error message is: "runtime error: load of address 0x7ffe8df74630 with
insufficient space for an object of type 'struct MemPage *'".
== OUR WORK-AROUND
The SQLite check-in 2025-06-26T18:57Z
<https://sqlite.org/src/info/2025-06-26T18:57Z> clears the problem for us. In
the very simple diff shown on the link, I think the code on both the right and
the left should be valid and should give the same result. Yet, only the right
side works with gcc-ubsan when optimization is enabled.
== REPRO INSTRUCTIONS
* Download <https://sqlite.org/tmp/gcc-ubsan-20250626.tar.gz>
* Untar
* `gcc -O1 -fsanitize=undefined shell.c sqlite3.c -lm -ldl -lpthread`
* `./a.out <ub1.txt`
== OUR ANALYSIS
Both variables apNew and apOld are automatic fixed-size arrays of pointers to
MemPage. They are different size arrays, which is what I suspect is confusing
UBSAN, but that should not matter, since when those symbols are used without a
`[...]` suffix, they should be interpreted as pointers to pointers to MemPage.
But apparently UBSAN does not like that.
The problem only arises with optimization enabled.
We have observed the problem in both gcc 13.3.0 and gcc 14.2.0
== BACKGROUND
See discussion at <https://sqlite.org/forum/forumpost/1d7c25d4a2d6f5e2>
