Segmentation fault on Connection::open

[LJason77]

With the latest version(0.24.2), Segment error in docker

let connection = Connection::open("config/date.db");

Segmentation fault is bound to occur whether or not the db file exists.

Everything is fine on the host, but inside docker there is a segment error.

sqlite-libs (3.32.1-r0)
sqlite-dev (3.32.1-r0)
Alpine Linux in docker
host : x86_64

[thomcc]

It being Alpine Linux I'm guessing this has to do with incompatible libcs or something... Hrm.

[hhirtz]

I've also encountered this problem on alpine. It happens when calling sqlite3_libversion_number (i guess this is the first C call made by the library in Connection::open?).

The compilation flags used to build sqlite3 on alpine [0] may be incompatible with the use of those bindings. Should I find the motivation I'll post which flag is problematic.

In the mean time, using the bundled feature makes it work.

[0] https://git.alpinelinux.org/aports/tree/main/sqlite/APKBUILD#n49

[monoclex]

I've ran into this issue. I sadly don't have anything of importance to add, but can confirm that using the bundled feature works.

[firefart]

I've run into the same issue when building arti :

https://gitlab.torproject.org/tpo/core/arti/-/issues/571

Any update on this issue?

[thomcc]

It's most likely an issue with your build, often because you're linking and running against different libcs (or the same libc in different configurations, as with alpine).

[thomcc]

Yeah you're using alpine too. In general you can't use either of the the standard x86_64-unknown-linux-gnu or x86_64-unknown-linux-musl targets. The first is the wrong libc, the second is the right libc, but Rust configures it to do static linking (the musl targets have the crt-static target feature enabled and statically link to libc), since rustc didn't expect people to want to use musl dynamically linked (which is what alpine does) back when these targets were added, since that wasn't a thing anybody did.

You might be able to make it work by using x86_64-unknown-linux-musl and also setting -Ctarget-feature=-crt-static when building, so RUSTFLAGS=-Ctarget-feature=-crt-static cargo build --target=x86_64-unknown-linux-musl. I'm not 100% sure this will do the trick though, it might be up to whether or not the cc crate picks up on it, or if something else is broken.

Another way to get it to work is to not use alpine -- sadly using dynamically linked musl is weird enough that it's not 100% supported out of the box. If there's something I can do on my end to make it work better I'll do it (if there aren't major drawbacks), but I'm not sure there is until rustc decouples the assumptions about static linking from its musl targets.

[trinity-1686a]

Just tried it, target-feature takes no final 's', but otherwise setting that RUSTFLAGS + target seems to work

[thomcc]

setting that RUSTFLAGS + target seems to work

Good to know. Glad to hear that it's as simple as passing some build options, and that they're build options that make sense to fix this.

I think there's nothing rusqlite can do to fix this then, since it's an issue with how things were built, so is more of a rustc/cargo thing (and making the situation on dynamic musl systems like alpine better is something that the rust project hopes to do, IIRC).