Thanks for sending the bug report, Ian. Unfortuantely, the repro script did not work for me. I think you sent the wrong file. Nevertheless, I was able to track down and fix the problem based on your description. A fix is on trunk.
To the rest of the world: the problem was in the command-line shell program in one of the "dot-commands", not in the SQLite core. An uninitialized variable got passed as a string argument to printf() and then (depending on what random location that uninitialized variable pointed to) printf() tried to get the string length and ran off the edge of the world. Fixed now on trunk. I was not actually able to repro the problem. But that I mean, I was never able to come up with a command-line shell input that would actually leave the variable uninitialized. I think it might require linking a recent version of SQLite command-line shell code against an older and/or customized shared library of the SQLite core. Whatever the cause, the variable is now always initialized and so there should not be any further problems. On 1/21/17, ian <[email protected]> wrote: > To Whom it may Concern: > > While performing some work with SQLite3, our team discovered a set of > inputs that, when passed to SQLite3, would trigger a segmentation fault. > I have attached both a write up of our findings while investigating the > fault (SQLite3 Writeup.docx), and a minimized version of the inputs that > were used to trigger the fault (minimal_crash.sql). Feel free to contact > me for any additional details. > > Regards, > > Ian > > -- D. Richard Hipp [email protected] _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
