The very last thing SQLite does before the abort is an OP_OpenRead, but p->expired which triggers SQLITE_ABORT_ROLLBACK.
Using the sqlite3.c included with the Fossil version at issue, I put a breakpoint at line 78001 with an ignore count of 333369. The 333370th time that line hits is immediately before the opcode dispatch to OP_OpenRead. I'll continue to look into this, but I don't expect to figure it out on my own. On Nov 6, 2016 02:17, "Andy Goth" <andrew.m.g...@gmail.com> wrote: > First off, sorry I haven't been active on the mailing list. I just kind of > disappeared, I know. Work's been very busy with constant travel, and I only > have my phone for personal email. > > Next, why the flurry of activity the last few days? I finally got a few > days off work, and I wanted to make the most of them. I don't know when > I'll get time like this again. > > Down to business. My last check-in on andygoth-changes (9d5de8d7) seems to > trigger a very strange failure in SQLite. Sorry, I can't copy-and-paste > (phone), so I'll just describe. It dies due to ROLLBACK, but I'm in the > middle of a SELECT so I don't know why. If I precede my SELECT with a > single step of the same SELECT except minus the ORDER BY, then it works. > > See the check-in code and comment for more information, including a > workaround and a repeatable test case. >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
