Assertion failed: g.json.cmd.a && "json_mode_bootstrap() was not called!"

There were recently some JSON-related changes to updated many of the tests which may have inadvertently caused this.

Can you tell us which command you run which caused this?

If you're building from a previous version, please do "make clean" and rebuild - on rare occasion (but it's been a while) i've seen cross-wiring of JSON-aware and non-JSON-aware objects when building first without it, then with it, without doing a clean rebuild between them.

I built in a fresh Docker container using the commands for Docker described here, but with --enable-json appended to the ./configure.

built in a fresh Docker container using the commands for Docker described here, but with --enable-json appended to the ./configure.

What fossil command are you running which triggers the problem? i've been unable to reproduce it with the commands i tried.

It it possible that your docker is building from an older or non-trunk version?

Mine docker-built version is:

./fossil version -v
This is fossil version 2.12 [918bcfcf77] 2020-07-08 13:53:52 UTC
Compiled on Jul  8 2020 14:55:19 using gcc-9.3.0 (64-bit)
Schema version 2015-01-24
Detected memory page size is 4096 bytes
zlib 1.2.11, loaded 1.2.11
hardened-SHA1 by Marc Stevens and Dan Shumow
SSL (OpenSSL 1.1.1g  21 Apr 2020)
JSON (API 20120713)
UNICODE_COMMAND_LINE
FOSSIL_STATIC_BUILD
SQLite 3.33.0 2020-06-20 03:43:46 067291143a
SQLITE_DEFAULT_FILE_FORMAT=4
SQLITE_DEFAULT_WAL_SYNCHRONOUS=1
SQLITE_ENABLE_DBSTAT_VTAB
SQLITE_ENABLE_FTS4
SQLITE_ENABLE_FTS5
SQLITE_ENABLE_JSON1
SQLITE_ENABLE_LOCKING_STYLE=0
SQLITE_ENABLE_STMTVTAB
SQLITE_LIKE_DOESNT_MATCH_BLOBS
SQLITE_MAX_EXPR_DEPTH=0
SQLITE_OMIT_DECLTYPE
SQLITE_OMIT_DEPRECATED
SQLITE_OMIT_LOAD_EXTENSION
SQLITE_OMIT_PROGRESS_CALLBACK
SQLITE_OMIT_SHARED_CACHE
SQLITE_THREADSAFE=0
SQLITE_USE_ALLOCA

My Dockerfile looks like:

FROM    alpine:edge

RUN apk update && apk upgrade                  \
    && apk add --no-cache                      \
      curl gcc make tcl musl-dev               \
      openssl-dev zlib-dev openssl-libs-static \
      zlib-static

ARG repoUrl=https://www.fossil-scm.org/fossil
ARG version=trunk
ARG cachebust=0
RUN curl                                  \
      "${repoUrl}/tarball/fossil-src.tar.gz?name=fossil-src&uuid=${version}"  \
      -o fossil-src.tar.gz                   \
      && tar xf fossil-src.tar.gz            \
      && cd fossil-src                       \
      && ./configure                         \
      --static                               \
      --disable-fusefs                       \
      --json                                 \
      && make

Thanks for the Dockerfile! I will try it!

I compiled with your Dockerfile, and still getting the same error:

Assertion failed: g.json.cmd.a && "json_mode_bootstrap() was not called!" (./src/json.c: json_page_top: 2278)

This is my Supervisor config:

[program:fossil]
process_name=%(program_name)s_%(process_num)02d
command=/usr/local/bin/fossil server /var/www/fossil --https --port 8079
autostart=true
autorestart=true
user=fossil
numprocs=1
redirect_stderr=true
stdout_logfile=/var/www/fossil/fossil.log
stopwaitsecs=3600

EDIT: the CLI seems to work fine, though. The problem is with HTTP, apparently.

EDIT: I checked the code, and I think the HTTP interface is not calling json_mode_bootstrap(), so it throws that assertion.

This is my Supervisor config:

i have no idea what a Supervisor is.

EDIT: the CLI seems to work fine, though. The problem is with HTTP, apparently.

Which page(s) is/are failing for you?

With the current trunk, built using the docker file shown above, i am unable to reproduce the problem you're reporting, using both local server/UI mode and CGI. e.g.:

• https://fossil.wanderinghorse.net/r/cwal/
• https://fossil.wanderinghorse.net/r/cwal/json/version

A random selection of 6 or 8 pages all work as expected with both HTTP and HTTPS.

Running it locally on a directory of .fossil files, similar to what your supervisor config appears to be doing, is also working for me:

$ l foo/
total 257868
drwxrwxr-x 2 stephan stephan      4096 Jul  8 20:32 .
drwxrwxr-x 3 stephan stephan      4096 Jul  8 20:32 ..
-rw-r--r-- 1 stephan stephan  43687936 Jul  8 20:32 cwal.fossil
-rw-r--r-- 1 stephan stephan 220356608 Jul  8 20:32 fossil.fossil

$ ./fossil server $PWD/foo --port 8079
Listening for HTTP requests on TCP port 8079

:-?

I repeated the steps, using the same Dockerfile and copying the binary to /usr/local/bin, and the problem persists. I'm using an NGINX reverse proxy, secured with Certbot, this is (part of) my config:

location ~* ^(\/(\w+).(html|css|js)|\/)$ {
    gzip_static on;
    try_files $uri $uri/ =404;
}

location / {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_pass http://127.0.0.1:8079;
}

The command I'm running is the same: /usr/local/bin/fossil server /var/www/fossil --https --port 8079. NGINX will always return 502 for any request to the JSON API, because the process crashes with the same json_mode_bootstrap() assertion. Could you please try the API with some of my repos at fossil.avalos.me?

Could you please try the API with some of my repos at fossil.avalos.me?

"502 Bad Gateway", which gives me no indication at all of what the problem is :/. If an assertion is being triggered i would expect a "500 internal server error", but your proxy might be "helpfully translating" that result to a 502.

i am completely unfamiliar with running nginx and have never heard of certbot, so cannot readily duplicate your specific configuration locally. You're the first person to report this, so my assumption is that there's something specific to that constellation which is triggering a code path in which json_mode_bootstrap() is not being called. If you can somehow capture a stack trace of what leads up to the assertion, that would be extremely helpful, but i cannot say how you might go about doing that under such a setup :/.

It's quickly approaching bedtime in my timezone, so i am unlikely to respond again until tomorrow. As it stands, though, i'm unable to reproduce the problem locally, so have no clue what is triggering it.

Are you able to try with a fossil built without docker, so that we can eliminate that variable? It seems unlikely that that would make any difference, but it's worth ruling out.

As it stands, though, i'm unable to reproduce the problem locally, so have no clue what is triggering it.

i've managed to reproducing by simply accessing /json/version in a repo accessed via "directory mode." That gives me an idea about what the problem is (fossil determines whether it's running in JSON mode based on the path, and that path apparently changes when run in that mode). i should have a fix for you by mid-day tomorrow (CET).

NGINX will always return 502 for any request to the JSON API

I believe that means the reverse proxy call failed, which isn’t enough info to diagnose it.

Try using curl or similar against Fossil directly on localhost.

Assuming that works, then you need to dig into the nginx logging to see what’s failing. IIRC, logging is nearly disabled by default in the name of speed, so you’ll probably have to dial it up to get useful results.

These are the NGINX logs, I always enable them by default, but this time I forgot about it.

2020/07/08 19:12:01 [error] 6192#0: *6067 upstream prematurely closed connection while reading response header from upstream, client: 3.13.12.160, server: fossil.avalos.me, request: "GET /personal-website/json/anonymousPassword HTTP/1.1", upstream: "http://127.0.0.1:8079/personal-website/json/anonymousPassword", host: "fossil.avalos.me"

Assertion failed: g.json.cmd.a && "json_mode_bootstrap() was not called!" (./src/json.c: json_page_top: 2278)

This has been resolved:

https://fossil-scm.org/fossil/info/dd490d17bec777c4

Thank you for the report!

Summary: when running in "directory mode", the HTTP path gets prefixed with "/reponame", and the JSON API did not (by design) recognize that as a valid route into the JSON API. When, much later, the handling was dispatched to the JSON API, the assertion assuring that we had indeed setup the JSON-related internals triggered (as it should have). So... this was all happening by design, but the design wasn't aware of the "/reponame" prefix case in that particular server mode.

Sidebar @Joe M.: this was completely unrelated to the recent JSON changes. This problem seems to have been around since the beginning, but apparently nobody used the JSON API via such servers, so never triggered it (or never reported it). (If indeed it worked before the recent changes, i'm not sure how.)

Wow, that was fast! Thanks! I didn't read the "this has been solved" part, I will try it! :D