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.