GitLab

I have an Epiphany crash report (when running under snap):

(gdb) bt full
#0  0x00007f20a95fd8da in open_in_default_handler (uri=0x5596afcbbd90 "file:///home/jena/Sta%C5%BEen%C3%A9/Capture_d_%C3%A9cran_vid%C3%A9o_de_14-05-2019_17_26_27.webm", 
    mime_type=0x7f20a961dbde "inode/directory", timestamp=11116828, screen=0x0, tag=EPHY_FILE_HELPERS_I_UNDERSTAND_I_MUST_NOT_USE_THIS_FUNCTION_UNDER_FLATPAK)
    at ../lib/ephy-file-helpers.c:689
        context = 0x5596afd60b10
        appinfo = 0x0
        error = 0x0
        uris = {data = 0x5596afcbbd90, next = 0x0, prev = 0x0}
        __func__ = "open_in_default_handler"
#1  0x00007f20a95fd9db in ephy_file_browse_to (file=0x5596b1a5d600, user_time=11116828, tag=EPHY_FILE_HELPERS_I_UNDERSTAND_I_MUST_NOT_USE_THIS_FUNCTION_UNDER_FLATPAK)
    at ../lib/ephy-file-helpers.c:724
        uri = 0x5596afcbbd90 "file:///home/jena/Sta%C5%BEen%C3%A9/Capture_d_%C3%A9cran_vid%C3%A9o_de_14-05-2019_17_26_27.webm"

Problem is g_app_info_launch_uris() has returned FALSE, so Epiphany dereferences error->message to print an error message, but error is NULL. I don't think Epiphany should add a NULL check, because this function is documented to always set error when it fails, in accordance with usual GLib convention: "On error, error will be set accordingly." Returns: "TRUE on successful launch, FALSE otherwise." I assume non-successful launch is an error, as would a reasonable developer.

I see g_desktop_app_info_launch_uris() calls g_desktop_app_info_launch_uris_internal(), which can only fail if it calls g_desktop_app_info_launch_uris_with_spawn(). That can only fail in expand_application_parameters() or g_spawn_async_with_fds() (or another case where the error is always set). g_spawn_async_with_fds() is explicitly documented to return "TRUE on success, FALSE if an error was set". expand_application_parameters() has two error paths: one where it always sets error itself, and one in g_shell_parse_argv(), which again is documented to return "TRUE on success, FALSE if error set". I haven't tracked this further, but I guess the bug lies in one or the other.