Error 1264 Out of range value with Docker/Alpine

[donut]

Repo reproducing the issue.

I'm trying to get caqti to work in an Alpine Docker container. Everything works, except I've run into this error:

Failed: Request to mariadb://root:@db/goomba failed: Error 1264, Query: "INSERT INTO test_sql (i, s) VALUES (?, ?)".
Fatal error: exception Request to mariadb://root:@db/goomba failed: Error 1264, Query: "INSERT INTO test_sql (i, s) VALUES (?, ?)".

The values passed are (1, "one"). See bin/main.ml.

The related Dockerfile:

### Build esy ###
# Adapted from https://github.com/andreypopp/esy-docker/blob/eae0eb686c15576cdf2c9d05309a2585b0a3e95e/esy-docker.mk

# start from node image so we can install esy from npm

FROM node:10.15-alpine as esy-build

ENV TERM=dumb \
  LD_LIBRARY_PATH=/usr/local/lib:/usr/lib:/lib

RUN mkdir /esy
WORKDIR /esy

ENV NPM_CONFIG_PREFIX=/esy
RUN npm install -g --unsafe-perm esy@0.5.6

# now that we have esy installed we need a proper runtime

FROM alpine:3.9 as esy-bin

ENV TERM=dumb \
  LD_LIBRARY_PATH=/usr/local/lib:/usr/lib:/lib

WORKDIR /

COPY --from=esy-build /esy /esy

RUN apk add --no-cache \
  ca-certificates wget \
  bash curl perl-utils \
  git patch gcc g++ musl-dev make m4

RUN wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub
RUN wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.28-r0/glibc-2.28-r0.apk
RUN apk add --no-cache glibc-2.28-r0.apk

ENV PATH=/esy/bin:$PATH


### Development environment ###
FROM esy-bin as development

# Niceties
RUN apk add --no-cache fish vim

# Needed for @esy-ocaml/libffi@3.2.10
RUN apk add --no-cache texinfo
# Needed for @opam/tls
RUN apk add --no-cache gmp-dev
# Needed for @opam/caqti-driver-mariadb
RUN apk add --no-cache mariadb-dev

RUN mkdir /app
WORKDIR /app

ENTRYPOINT ["tail", "-f", "/dev/null"]

[donut]

Forgot to mention, I found a workaround using the ubuntu:bionic Docker image: https://github.com/donut/bug.ocaml-caqti-mariadb-alpine-docker/tree/ubuntu-workaround

[paurkedal]

Yes, I tried that image myself, and there it worked. It probably depends on the libmariadb version.

Update: Sorry that was misleading, I tested with a generic Ubuntu 18.04 image, not the one you cited.

[donut]

mariadb-dev is the relevant package used in Alpine. I tried matching up the mariadb version in the db service to no avail. But I might be making connections out of my ignorance in this case.

[paurkedal]

The version is not far off from the Ubuntu 18.04 actually. I am mostly wondering if it's a mis-linkage issue, either during build vs run of the OCaml buildings or with the libc. I'm new to the esy package manager, so I've just been exploring a bit, and I'm not whether such a linkage issue could occur.

[paurkedal]

In the same container I cloned https://github.com/andrenth/ocaml-mariadb.git, built it with esy install && esy build and set the OCAML_MARIADB_* used in the source and:

/app/ocaml-mariadb # _esy/default/store/b/ocaml_mariadb-b694e0d8/blocking_stress_test.native 
Fatal error: exception Failure("field '?' is not a string")
/app/ocaml-mariadb # _esy/default/store/b/ocaml_mariadb-b694e0d8/nonblocking_select_stress_tes
t.native 
Res.fetch: (2032) truncated data

The errors are different, but I think they also indicate issues with serialization or communication of parameters.

[donut]

Here's another error that I forgot to mention that I ran into related to serialization. Using caqti to run the prepared statement DELETE FROM source WHERE id = ? LIMIT 1, passing in the integer 5 for the value I got this executed:

190417 11:16:28	     8 Connect	ovp_sync@192.168.32.3 as anonymous on ovp_sync
		     8 Prepare	SET time_zone = '+00:00'
		     8 Execute	SET time_zone = '+00:00'
		     8 Close stmt
		     8 Prepare	DELETE FROM source WHERE id = ? LIMIT 1
		     8 Execute	DELETE FROM source WHERE id = 139749645877253 LIMIT 1
		     8 Reset stmt
		     8 Close stmt
		     8 Quit

Each time I ran this the number would be different. Strings passed in fine, but not integers.

[paurkedal]

I could reproduce the blocking_stress_test.ml failure from the opam package in the same container, so at least I think we can exclude the issue being node/esy specific.

The latest failure you posted, esp. the random nature of the error, also suggests some memory issue or incompatibility with the C bindings.