In [this thread](https://sqlite.org/forum/forumpost/ed69634b36), I noted that the leak discovered and reported by its OP could be reproduced. I have since simplified the repro input and diagnosed where and why the leak occurs. If sqlite3.exe (or any other platform's executable) is given this input: ``` .i |junk (Not(SQL .q ``` , the .import command handler will take an error exit whereby some memory held by the sCtx struct variable is never freed (except by process clean-up.) The exiting code, with an added statement (marked by 'NEW CODE ...' below) does not leak, which demonstrates the leak mechanism. Said code reads: ``` sqlite3_free(zSql); if( rc ){ if (pStmt) sqlite3_finalize(pStmt); utf8_printf(stderr,"Error: %s\n", sqlite3_errmsg(p->db)); xCloser(sCtx.in); sqlite3_free(sCtx.z); /* NEW CODE, copied from elsewhere in shell.c */ rc = 1; goto meta_command_exit; } nCol = sqlite3_column_count(pStmt); ``` I hereby disclaim any and all rights to that added code, and acknowledge that it is merely a copy of the very same statement found in some nearby lines. This is not a patch; it is just a demonstration of how to plug one little leak. The issue and code relate to SQLite v3.32.1 and many earlier versions.