SQLITE_MISUSE on clone
(1) By andygoth on 2020-07-18 00:59:45
The following commands: > mkdir fossil-crash cd fossil-crash fossil open ~/repos/fossil.fossil f8d210aa1c150d13d6ca9d58abf9cec461e4b8c4 ./configure make ./fossil clone http://fossil-scm.org/ fossil.fossil result in this error: > SQLITE_MISUSE(21): API call with NULL database connection pointer SQLITE_MISUSE(21): misuse at line 128813 of [067291143a] Database error: out of memory SELECT value FROM config WHERE name='sync-url:http://fossil-scm.org/' The same failure happens with other protocols besides `http`. Bisection reveals the failure was introduced by [f11c863d91c251d0](https://fossil-scm.org/home/info/f11c863d91c251d0), which is a shame because I could use that feature on this project.
(2) By andygoth on 2020-07-18 01:34:37 in reply to 1 [link]
For now I've backed out the commit in question, along with a few things downstream of it. Here's the backout: <https://fossil-scm.org/home/info/0a7526522085631f>.
(3) By andygoth on 2020-07-18 04:28:19 in reply to 2 [link]
Now fixed, thanks to <https://fossil-scm.org/home/info/857777f117eb0d5a>.
(4) By Marcelo Huerta (richieadler) on 2020-07-18 16:36:15 in reply to 3 [link]
I am glad, one of my personal projects really benefits of the multi-remotes autosyncing all at once.
(8) By andygoth on 2020-08-17 00:30:25 in reply to 4 [link]
The multi-remotes don't all autosync at once. Only the default remote syncs. "[The default remote is used by autosync.](https://fossil-scm.org/home/file?ln=375-376&ci=de38906f&name=src%2Fsync.c)" I have wanted automatic sync'ing of multiple remotes, but this is not implemented. See my [thread](/forumpost/e5477060c6) on this topic.
(5) By andygoth on 2020-07-30 00:13:08 in reply to 1 [link]
Turns out there's another problem now, introduced either by the original change [f11c863d91c251d0](https://fossil-scm.org/home/info/f11c863d91c251d0) or by the correction [857777f117eb0d5a](https://fossil-scm.org/home/info/857777f117eb0d5a). I used a bisect to confirm this is when things went wrong. Cloning from one filesystem file to another results in the following: > $ fossil clone a.fossil b.fossil SQLITE_ERROR(1): no such table: global_config in "DELETE FROM global_config WHERE name = 'repo:/home/andy/test/b.fossil';" Database error: no such table: global_config: {DELETE FROM global_config WHERE name = 'repo:/home/andy/test/b.fossil';} For now, I brought back the [temporary-fix](https://fossil-scm.org/home/timeline?r=temporary-fix) to include everything but the multi-remote capability.
(6) By andygoth on 2020-08-16 15:15:13 in reply to 5 [link]
To better reflect its purpose, I renamed the branch from temporary-fix to [multi-remote-fix](https://fossil-scm.org/home/timeline?r=multi-remote-fix). I compared the output of `fossil -sqltrace` between [trunk](http://fossil-scm.org/home/info/dcc90ab5e1b49b1b) and [multi-remote-fix](http://fossil-scm.org/home/info/719dcd29cd8a99d5). This revealed the problem to be use of [db_close_config()](https://fossil-scm.org/home/file?name=src/db.c&ci=dcc90ab5e1b49b1b&ln=1449-1561) before *later* attempting to call [db_record_repository_filename()](https://fossil-scm.org/home/file?name=src/db.c&ci=dcc90ab5e1b49b1b&ln=3042-3045). db_close_config() is called by [db_close()](https://fossil-scm.org/home/file?name=src/db.c&ci=dcc90ab5e1b49b1b&ln=2129), itself called by [clone_cmd()](https://fossil-scm.org/home/file?name=src/clone.c&ci=dcc90ab5e1b49b1b&ln=170) due to the source repository being a local file. db_record_repository_filename() is called by [clone_cmd()](https://fossil-scm.org/home/file?name=src/clone.c&ci=dcc90ab5e1b49b1b&ln=172), just two lines after it called db_close(). Gonna work on this some more.
(7) By andygoth on 2020-08-16 15:25:49 in reply to 6 [link]
In [multi-remote-fix](http://fossil-scm.org/home/info/719dcd29cd8a99d5), the first major difference I see is db_close() does not call db_close_config() because [g.db is NULL](https://fossil-scm.org/home/file?name=src/db.c&ci=719dcd29cd8a99d5&ln=2090). Thus, the configuration table is open and the global_config table still exists by the time db_record_repository_filename() tries to access it. In [trunk](http://fossil-scm.org/home/info/dcc90ab5e1b49b1b), g.db is non-NULL, leading to the errors I've been experiencing, namely the configuration database being closed before db_record_repository_filename() can get to it. g.db is non-NULL because the multi-remote feature modified url_parse_local() to call db_get() in support of the "URL" actually being the alias for a previously-registered remote URL.
(9) By andygoth on 2020-08-17 08:07:09 in reply to 7 [link]
Fixed, thanks again to drh. ([Check-in](https://fossil-scm.org/home/info/9d2b7cab7ac64cf8))