Go 1.24 compatibility #227
Comments
|
This looks like tetratelabs/wazero#2375. I haven't had the time to look into it. I had tested with internal RC builds of 1.24, so I thought SQLite might be OK. |
|
For what it's worth I've been using go-sqlite3 over the last couple months with Go tip as it's led up to 1.24 without issues, both on darwin/arm64 and linux/amd64. For example I have a project I started the other day that's using github.com/ncruces/go-sqlite3 v0.22.0 and github.com/tetratelabs/wazero v1.8.2, built mostly recently with go1.25-215de81513. |
|
Right. Me too. So this has really caught me off guard. @olivier-m can you tell us more, at a minimum: OS, architecture, etc? If you can create a smaller reproducer, it might also be helpful. |
|
👍 I just tried adding various things I see in sqlite.go here that I don't typically use (memdb, pragmas, etc) to one of my projects and couldn't get it to break at least, on darwin/arm64 with go1.25-43b7e67040. |
|
Also tests seem to pass in CI: With the exception of wasip1, which might have to do with that port's changes (might be as simple as the way tests must run with |
Standard intel 64bit (core i7) on linux:
Here you go: package main
import (
"fmt"
"os"
"runtime"
"github.com/ncruces/go-sqlite3/driver"
_ "github.com/ncruces/go-sqlite3/embed"
)
func main() {
fmt.Printf("Go version: %s\n", runtime.Version())
if err := os.Remove("test.db"); err != nil {
if !os.IsNotExist(err) {
panic(err)
}
}
db, err := driver.Open("file:test.db?_txlock=immediate&_timefmt=auto")
if err != nil {
panic(err)
}
if _, err = db.Exec(`
PRAGMA busy_timeout = 5000;
PRAGMA foreign_keys = 1;
PRAGMA journal_mode = WAL;
PRAGMA mmap_size = 30000000000;
PRAGMA cache_size = 1000000000;
PRAGMA secure_delete = 1;
PRAGMA synchronous = NORMAL;
PRAGMA temp_store = memory;
`); err != nil {
panic(err)
}
if _, err = db.Exec(`
CREATE TABLE migration (
id integer PRIMARY KEY,
name text NOT NULL,
applied datetime NOT NULL
);
`); err != nil {
panic(err)
}
fmt.Println("all good!")
}Then built with Following @danp's hunch, I toyed with the PRAGMA settings and, indeed, there's a culprit. Thanks for the prompt answer :) Edit: I tried building the whole project without secure_delete but it now fails at the connection. |
|
If it's I'm betting It won't be the only usage of it, of course, but it makes sense that it adds more opportunities for We could try building SQLite without bulk memory but I guess it's simpler to just wait for the wazero fix. |
|
Thanks for your answer, since I don't urgently need any new feature in 1.24, I'll wait for a fix in wazero :) |
|
@olivier-m, can you try tetratelabs/wazero#2378? This should do it: go mod edit -replace github.com/tetratelabs/wazero=github.com/anuraaga/wazero@go-124-memmove
go mod tidy
# go test something? |
The app works (manual and e2e tests) and all tests pass. I'd say it's all good :) Thanks! |
Discussed in #226
Originally posted by olivier-m February 13, 2025
Hi,
I've migrated Readeck (https://codeberg.org/readeck/readeck) from mattn driver to yours and so far, so good. Thanks for your work, I really enjoy not needing CGO anymore :)
Out of curiosity, I compiled the project with Go 1.24.0 and it panics with an "out of bounds memory access". Here's the message:
This was on first launch during schema creation. On an existing database, it fails (same error) with some specific requests but not all of them.
If you'd like to reproduce, you can compile with:
make setup && make generate && make buildafter changing the go value to 1.24 in go.mod. I don't know if that's an issue on your side, wazero or somewhere else. Let me know if I can perform more tests.PS: the migration to WASM was done in this branch: https://codeberg.org/readeck/readeck/pulls/411/files
The text was updated successfully, but these errors were encountered: