"Reveal" feature causes the app to segfault on linux in some cases about opener

[Seeker14491]

No idea what caused the issue. It does seem dbus related given that backtrace, but I don't have any dbus internals expertise that would give me an idea of why this crash happened. Given that the original issue was resolved by reinstalling Arch, I'm going to assume it was some issue with the Arch install, and will close this issue.

[qu1ck]

I believe root cause of the crash is statically linked dbus lib. See more here
https://internals.rust-lang.org/t/global-symbols-from-statically-linked-system-libraries/19954

It causes some global variables to not be initialized correctly which could manifest into a crash with a stack trace above.

Is there any reason why you use vendored feature here?

opener/opener/Cargo.toml

Line 31 in ff6e259

dbus = { version = "0.9", optional = true, features = ["vendored"] }

My understanding is that without it the lib will be not be statically linked so it may solve the above crash. Would it create other problems?

[Seeker14491]

The reason for using the vendored feature is to avoid needing dbus's usual dependencies to both build opener, and run executables that use opener.

[qu1ck]

I don't understand how static linking helps avoid any dependencies. Doesn't the other end of what dbus talks to need dbus dependencies anyway?

Can you make it optional at least?

[Seeker14491]

On the development side, the vendored feature avoids needing dbus's library dependencies for compiling the library. On the user side, the vendored feature lets them run the built binaries, even if they lack the dbus runtime library (though that's rare). In that case the dbus functionality won't work, but they can still run the program.

I can make the vendored dbus feature optional, by adding a new feature flag to opener that controls it. I think I can also keep vendoring as the default, and therefore avoid making this a breaking change.

[qu1ck]

I can make the vendored dbus feature optional, by adding a new feature flag to opener that controls it. I think I can also keep vendoring as the default, and therefore avoid making this a breaking change.

That would resolve the issue for me.

[Seeker14491]

Alright, I implemented this in a9dc2ee. It's technically a breaking change though if someone was using default-features = false for some reason. There's another unrelated PR I want to resolve (#28), then I plan on making a release.

As for the true underlying issue, if it's a Rust or Cargo bug we should open an issue in the appropriate place, if one hasn't been made.

[qu1ck]

I'm not well versed enough in linker intricacies to file proper bug report with reproducible example, I'm just going off Nvidia engineer's analysis in the rust-lang forum thread I linked above. That thread just got closed for inactivity, sadly.

If it helps, I believe the whole investigation started from this webkitgtk bug report https://bugs.webkit.org/show_bug.cgi?id=261874#c57 (link to nvidia driver dev's comment explaining crash in my app)

[Seeker14491]

I've released opener v0.7.0.

[username227]

Please note that with the new version, the program will only render properly when started WITHOUT the environment variable contained in the .desktop file.
If I start the latest commit with the .desktop file then it renders a white screen.
Therefore, please push out a corrected desktop file. If the aur pkgbuild needs updating, i can do the same thing as last time, just tell me the direct download link to use in the pkgbuild.
Thanks.

[qu1ck]

@username227 please open an issue for that on TrguiNG issue tracker, it is not relevant to this repo.