You're welcome. It was not clear to me from the crash evidence that the bug has been resolved. Depending on why an access fault occurs, the defect that leads to an invalid pointer may still exist even if it is not dereferenced. In general, with C/C++ code, absence of access faults does not imply absence of bugs. Invalid pointers can accidentally refer to mapped memory and be dereferenced without the memory management hardware detecting an invalid access. Likewise, access faults do not, by themselves, imply a bug in the code that was executing when the fault occurs. This is especially true with libraries which run in the same process as other code which may or may not be well behaved. However, as shown below, there is reason to believe this bug has been fixed.
Somewhere in the SQLite docs, this forum is said to be the place to report bugs. That is more or less done with your first post combined with mine demonstrating that 3rd party code cannot be responsible for the fault. You might edit your first post to change the subject to contain the word "bug". As I next show, "bug, resolved" would be better yet IMO.
Interestingly, the code shown in your first post cannot be found in the nearing-release version of SQLite, at least not exactly. The crashing code is:
```
if( (pExpr->pLeft->op==TK_COLUMN && IsVirtual(pExpr->pLeft->y.pTab))
|| (pExpr->pRight->op==TK_COLUMN && IsVirtual(pExpr->pRight->y.pTab))
){
return WRC_Prune;
}
default:
return WRC_Continue;
```
whereas today's version of the code handling the same case in the same optimization function is:
```
/* The y.pTab=0 assignment in wherecode.c always happens after the
** impliesNotNullRow() test */
if( (pLeft->op==TK_COLUMN && ALWAYS(pLeft->y.pTab!=0)
&& IsVirtual(pLeft->y.pTab))
|| (pRight->op==TK_COLUMN && ALWAYS(pRight->y.pTab!=0)
&& IsVirtual(pRight->y.pTab))
){
return WRC_Prune;
}
```
This leads me to believe that, in fact, the bug is resolved in v3.32-to-be.