gio::auto::file::File::new_for_path runs into nullptr on musl

[Cogitri]

Hello,

In tracker-rs examples gio::auto::file::File::new_for_path crashes with a SIGSEGV because it runs into a nullpointer. The backtrace:

#0  0x0000000000000000 in ?? ()
#1  0x00007f4e19d8f9bb in gio::auto::file::File::new_for_path<std::path::PathBuf> (path=...)
    at /root/.cargo/git/checkouts/gtk-rs-48ef14c1f17c79fb/295e8c1/gio/src/auto/file.rs:73
#2  0x00007f4e19d8eaf4 in tracker_resource::main () at /tracker-rs/examples/src/bin/tracker_resource.rs:16

Here's a Dockerfile for a reproducer:

FROM alpine:latest
RUN apk add tracker-dev rustup git build-base \
    && rustup-init -y \
    && source $HOME/.cargo/env \
    && git clone https://gitlab.com/dleggo/tracker-rs \
    && cd tracker-rs/examples \
    && cargo build \
    && ./target/debug/tracker_resource

[sdroege]

That would be a bug in GLib/GIO or the GVfs implementation used there. The function must never return NULL:

This operation never fails, but the returned object might not support any I/O operation if path is malformed.

Please report it with a testcase here: https://gitlab.gnome.org/GNOME/glib/-/issues/new

[Cogitri]

Will do, thanks :)

[george-hopkins]

@Cogitri Did you find the root cause of the issue? I'm facing a similar issue with File::new_for_commandline_arg. Based on my mediocre debugging skills, my SIGSEGV occurs in the Rust binary before (or exactly where) the call to the shared library should happen.

[Cogitri]

Yeah, the SEGFAULT occurs because gtk-rs assumes that that function can't return NULL (since it can't do that according to the docs). I have to admit I kind of forgot about this issue, so I didnt open an issue over at glib's repo

[GuillaumeGomez]

@george-hopkins Sending a fix for the function then.

[GuillaumeGomez]

@george-hopkins Actually, can you show us how you the call the function please?

[george-hopkins]

fn main() {
    let arg = std::env::args().skip(1).next().unwrap();
    println!("{:?}", gio::File::for_commandline_arg(arg));
}

Environment: rustc 1.52.1 on Alpine Linux (Docker container rust:alpine)

[george-hopkins]

I still think that the fault occurs before calling and returning from the shared library. It occurs on this call in the Rust binary:

mov    0x30(%rsp),%rdi       # %rdi is a pointer to arg (null-terminated)
call   *0x64b0f(%rip)        # 0x7ffff7ffced0       

0x7ffff7ffceb0: 0x00007ffff7fe5080      0x00007ffff7f9a250
0x7ffff7ffcec0: 0x00007ffff7f9b1a0      0x00007ffff7fda450
0x7ffff7ffced0: 0x0000000000000000      0x00007ffff7fe3960 # 0x7ffff7ffced0 should probably be a valid function pointer too
0x7ffff7ffcee0: 0x00007ffff7fc5860      0x00007ffff7fdaa98
0x7ffff7ffcef0: 0x00007ffff7fc6760      0x00007ffff7f9a510

[GuillaumeGomez]

Can you give a try to my fix please?

[george-hopkins]

Unfortunately, I still get a SEGFAULT with the fix applied.

[GuillaumeGomez]

So the problem isnt the returned value of the function but something else.

[george-hopkins]

After recompiling with RUSTFLAGS="-C target-feature=-crt-static" the issue seems to be resolved (might be related to rust-lang/rust#82193). Thanks for your help!

[sdroege]

This looks like either a GLib or musl bug, or an environment bug where you end up having multiple CRTs.

[Cogitri]

It's an environment bug. Using some random static musl version (from rustc) when you have shared libraries that are linked against the system musl copy is broken (same for using static musl from rustc and shared libs linked against glibc). There's currently some working being done in rust upstream to make musl shared by default and introduce a new static triplet so this won't happen anymore.