PolyMeilex / PolyMeilex/rfd

win: Repeated use of file dialog in asynchronous context causes access violation

Open
#280 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
830
Forks
108
Avg merge
6d 33m
Merged PRs (30d)
2

Description

I have a CLI tool which runs a prompt loop in an asynchronous Tokio context.

/// This gets called from `async main()`.
pub async fn prompt_loop() -> anyhow::Result<()> {
    loop {
        let selection = Select::with_theme(&*THEME)
            .with_prompt(...)
            .items(MenuOption::options())
            .default(0)
            .interact_opt()?;
        clearscreen::clear()?;

        match MenuOption::from_index(selection) {
            // ...
            Some(MenuOption::ImportSet) => import().await?,
            // ...
            _ => {}
        }
    }
}

async fn import() -> anyhow::Result<()> {
    info!("Select a folder of JSON files to continue...");

    let directory = FileDialog::new()
        .set_title("Select a folder of JSON files to import")
        .pick_folder()
        .ok_or_else(|| anyhow::anyhow!("No directory selected"))?;
    info!("Selected directory: {}", directory.display());

    // ...

    Ok(())
}

With this loop, I can access the file dialog once, but attempting to opening it again prints a cryptic:

10000 46000000
error: process didn't exit successfully: `executable.exe` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)

which is thrown when calling let directory = FileDialog::new().

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the Windows crash with the shown Tokio prompt_loop, calling FileDialog::new().pick_folder() more than once. Trace the Windows implementation reached by FileDialog::new() and verify that the fix allows the folder dialog to open repeatedly without STATUS_ACCESS_VIOLATION.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
desktop, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.