Worker thread for {target_file} failed to send results back

Error message

Worker thread for {target_file} failed to send results back to main thread: {e}

What it means

Panics inside spawn_worker when a worker thread finishes analyzing a file but the mpsc channel back to the main thread is closed (SendError). It means the main receiver was dropped — the result of the worker's work is lost, so the tool aborts.

Source

Thrown at src/main.rs:309

            Err(_) => {
                error!("Failed to read {target_file} data");
                b"".to_vec()
            }
            Ok(data) => data,
        };

        // Analyze target file, with extraction, if specified
        let results = bw.analyze_buf(&file_data, &target_file, do_extraction);

        // If data carving was requested as part of extraction, carve analysis results to disk
        if do_carve {
            let carve_count = carve_file_map(&file_data, &results);
            info!("Carved {carve_count} data blocks to disk from {target_file}");
        }

        // Report file results back to main thread
        if let Err(e) = worker_tx.send(results) {
            panic!(
                "Worker thread for {target_file} failed to send results back to main thread: {e}"
            );
        }
    });
}

/// Carve signatures identified during analysis to separate files on disk.
/// Returns the number of carved files created.
/// Note that unknown blocks of file data are also carved to disk, so the number of files
/// created may be larger than the number of results defined in results.file_map.
fn carve_file_map(file_data: &[u8], results: &binwalk::AnalysisResults) -> usize {
    let mut carve_count: usize = 0;
    let mut last_known_offset: usize = 0;
    let mut unknown_bytes: Vec<(usize, usize)> = Vec::new();

    // No results, don't do anything
    if !results.file_map.is_empty() {
        // Loop through all identified signatures in the file

View on GitHub (pinned to 26713972e3)

Solutions

Keep the receiver (worker_rx) alive until all workers have completed (join the pool before dropping rx)
Handle the send error gracefully (log and exit) instead of panicking inside the worker thread
Check main-thread logs for an earlier panic that dropped the receiver — fix that root cause
Consider using a scoped thread structure or explicit JoinHandle collection to guarantee rx outlives all senders

Example fix

// before
if let Err(e) = worker_tx.send(results) {
    panic!("Worker thread for {target_file} failed to send results back to main thread: {e}");
}
// after
if let Err(e) = worker_tx.send(results) {
    eprintln!("Failed to send results for {target_file}: {e}");
    return;
}

Defensive patterns

Strategy: try-catch

Validate before calling

// ensure receiver lives as long as senders
let (worker_tx, worker_rx) = mpsc::channel();
// keep worker_rx alive until workers.active_count() == 0 before dropping

Try / catch

if let Err(e) = worker_tx.send(results) {
    eprintln!("send failed: {e}");
    return; // or set an atomic shutdown flag
}

Prevention

Guarantee the channel receiver outlives all worker threads (join/await pool shutdown before dropping rx)
Fix root-cause panics in the main loop that drop the receiver early
Log send errors instead of panicking inside worker threads
Test worker shutdown ordering under load

When it happens

Trigger: The main thread's worker_rx receiver is dropped (main loop exited or panicked) before all workers finish, then a worker calls worker_tx.send(results) which returns Err(e) and hits the panic at src/main.rs:309.

Common situations: A panic in the main scheduler loop while workers are still running; process shutdown racing with in-flight workers; refactors that drop the receiver early.

Related errors

AI-assisted analysis of ReFirmLabs/binwalk@26713972e3 (2026-09-06). Data as JSON: /api/errors/6e112d165f5b7888. Report an issue: GitHub.