[PR #1812] [MERGED] fix(rust): prevent panics in timing code when processing multiple files #2552

Open
opened 2026-01-29 17:22:45 +00:00 by claunia · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/CCExtractor/ccextractor/pull/1812
Author: @cfsmp3
Created: 12/14/2025
Status: Merged
Merged: 12/14/2025
Merged by: @cfsmp3

Base: masterHead: fix/issue-1377-rust-panic


📝 Commits (2)

  • 0b262d0 fix(rust): prevent panics in timing code when processing multiple files
  • 80e2117 style: apply cargo fmt formatting

📊 Changes

2 files changed (+72 additions, -34 deletions)

View changed files

📝 src/rust/lib_ccxr/src/time/units.rs (+6 -3)
📝 src/rust/src/libccxr_exports/time.rs (+66 -31)

📄 Description

Summary

  • Fixes crashes (thread caused non-unwinding panic. aborting.) when processing multiple files with different characteristics (e.g., DVD-type followed by HDTV-type media)
  • Replaces unsafe .unwrap() and .expect() calls with safe alternatives throughout the Rust timing code
  • Handles RwLock poisoning gracefully to prevent cascading failures
  • Adds fps validation and millis capping in GopTimeCode::new() to handle edge cases
  • Adds fallback calculation when GopTimeCode creation fails due to out-of-spec values

Root Cause

The crash occurred because Rust code was using .unwrap() on type conversions and .expect() on Result values in extern "C" functions. When processing files with different characteristics sequentially, stale timing state from previous files could cause these conversions to fail, triggering panics. Since Rust panics cannot unwind across FFI boundaries, this resulted in immediate process termination.

Changes

  • src/rust/src/libccxr_exports/time.rs:

    • Use unwrap_or(0) for all try_into() conversions
    • Handle RwLock poisoning in apply_timing_info() and write_back_from_timing_info()
    • Refactor ccxr_calculate_ms_gop_time() to use safe fallback calculation
  • src/rust/lib_ccxr/src/time/units.rs:

    • Add fps validation (use 29.97 default for invalid fps)
    • Cap millis to 999 to prevent from_hms_millis failures
    • Replace .expect() with .ok()?

Test plan

  • Test with file combination that previously crashed (DVD-type → HDTV-type)
  • Test with 3+ files in sequence
  • Verify output files are produced correctly

Fixes #1377

🤖 Generated with Claude Code


🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/CCExtractor/ccextractor/pull/1812 **Author:** [@cfsmp3](https://github.com/cfsmp3) **Created:** 12/14/2025 **Status:** ✅ Merged **Merged:** 12/14/2025 **Merged by:** [@cfsmp3](https://github.com/cfsmp3) **Base:** `master` ← **Head:** `fix/issue-1377-rust-panic` --- ### 📝 Commits (2) - [`0b262d0`](https://github.com/CCExtractor/ccextractor/commit/0b262d0e17afe1a06b4ef7682edb7a070d882341) fix(rust): prevent panics in timing code when processing multiple files - [`80e2117`](https://github.com/CCExtractor/ccextractor/commit/80e21171b1d666cb319922392ac10f3b691b0ef1) style: apply cargo fmt formatting ### 📊 Changes **2 files changed** (+72 additions, -34 deletions) <details> <summary>View changed files</summary> 📝 `src/rust/lib_ccxr/src/time/units.rs` (+6 -3) 📝 `src/rust/src/libccxr_exports/time.rs` (+66 -31) </details> ### 📄 Description ## Summary - Fixes crashes (`thread caused non-unwinding panic. aborting.`) when processing multiple files with different characteristics (e.g., DVD-type followed by HDTV-type media) - Replaces unsafe `.unwrap()` and `.expect()` calls with safe alternatives throughout the Rust timing code - Handles RwLock poisoning gracefully to prevent cascading failures - Adds fps validation and millis capping in `GopTimeCode::new()` to handle edge cases - Adds fallback calculation when GopTimeCode creation fails due to out-of-spec values ## Root Cause The crash occurred because Rust code was using `.unwrap()` on type conversions and `.expect()` on Result values in `extern "C"` functions. When processing files with different characteristics sequentially, stale timing state from previous files could cause these conversions to fail, triggering panics. Since Rust panics cannot unwind across FFI boundaries, this resulted in immediate process termination. ## Changes - `src/rust/src/libccxr_exports/time.rs`: - Use `unwrap_or(0)` for all `try_into()` conversions - Handle RwLock poisoning in `apply_timing_info()` and `write_back_from_timing_info()` - Refactor `ccxr_calculate_ms_gop_time()` to use safe fallback calculation - `src/rust/lib_ccxr/src/time/units.rs`: - Add fps validation (use 29.97 default for invalid fps) - Cap millis to 999 to prevent `from_hms_millis` failures - Replace `.expect()` with `.ok()?` ## Test plan - [x] Test with file combination that previously crashed (DVD-type → HDTV-type) - [x] Test with 3+ files in sequence - [x] Verify output files are produced correctly Fixes #1377 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
claunia added the pull-request label 2026-01-29 17:22:45 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/ccextractor#2552