Created attachment 8870488 [details] firefox.asan.log User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Steps to reproduce: Running GCC 7 with -fsanitize=address one can see couple of use-after-scope errors.
Attachment #8870488 - Attachment mime type: text/x-log → text/plain
these are usually just false reports. Let's see what Richard thinks.
This is not something we've seen before. Investigating....
The available evidence suggests this is an issue with -fsanitize=address in GCC-7. See http://sqlite.1065341.n5.nabble.com/gnu-gcc-address-sanitizer-finds-stack-use-after-scope-in-sqlite3VdbeExec-td95428.html for a previous report of the same warning and speculation as to the cause. Note that we do run full-coverage tests using valgrind and -fsanitize=undefined, neither of which generate any warnings. That doesn't prove anything, but it is additional evidence that the problem is with GCC-7 and not SQLite. Next step: Install GCC-7 and see if we can repro the problem....
Hello, thanks for investigation. Note that I'm the author of use-after-scope sanitization in GCC 7. So if you have a reduced test-case, I'll be happy to fix it in GCC. Thanks.
Martin, I don't (yet) have a reduced test case, but I can reproduce the problem simply as follows: (1) Download the source files "shell.c", "sqlite3.c", and "sqlite3.h" from https://www.sqlite.org/2017/sqlite-autoconf-3190100.tar.gz (2) Run: "gcc-7 -g -fsanitize=address sqlite3.c shell.c -ldl -lpthread" (3) Run: ./a.out :memory: '.selftest --init' The use-after-scope error is reported on https://www.sqlite.org/src/artifact/70f1c27d3de?ln=4223 which is the initialization of a variable declared at https://www.sqlite.org/src/artifact/70f1c27d3de?ln=4201 The OP_NotExists opcode is being run. Notice how it enters the block after the point where the variable is declared. There is some speculation that this might be the origin of the warning. Can you confirm? Oddly, the error occurs on the 3rd invocation of the OP_NotExists opcode (according to gdb). It is unclear why this statement should fail the 3rd time through but work on the first two. Any insights you can offer are greatly appreciated.
Thanks, I can confirm that it's bug in GCC.
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Resolution: --- → INVALID
Upstream bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80879
You need to log in before you can comment on or make changes to this bug.