On Jan 23, 2020, at 8:33 AM, Bernhard Rosenkraenzer <b...@lindev.ch> wrote: > > The Debian guys have also observed this: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949644 > (and also don't have a fix yet). > > Any ideas?
Can you bisect SQLite to narrow the range here? This release had an unusually long period to cook, so without a bisect, you’re kind of asking for someone to remember what they changed months ago. Method: 1. Check out SQLite source from Fossil: https://sqlite.org/src/ 2. fossil bisect reset ; fossil bisect bad (marks tip-of-trunk as “bad”) 3. fossil bisect good version-3.30.1 (or whatever version you last tested as “good”) At that point, the source tree will contain a version halfway between tip-of-trunk and the version you marked “good” with the third command. Build it, test it, then say either “fossil bisect bad” or “fossil bisect good” depending on whether it crashes again. By my count, there have been 551 checkins between those two releases, so a bisect should take roughly 9 tries to find the culprit: $ fossil timeline after version-3.30.1 -t ci -n 0 | grep -c '^[0-9]' _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
