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

New Issue

claunia · 2026-01-29T17:22:45Z

claunia commented

2026-01-29 17:22:45 +00:00

Original Pull Request: https://github.com/CCExtractor/ccextractor/pull/1812

State: closed
Merged: Yes

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

**Original Pull Request:** https://github.com/CCExtractor/ccextractor/pull/1812 **State:** closed **Merged:** Yes --- ## 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)

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#2555