switch_to_next_file() re-enters itself through open(), advancing current_file twice
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 38/100
Direzione di ricerca
Inizia con la riproduzione in gdb, poi traccia switch_to_next_file in file_functions.c:116 e :181 e in src/rust/src/file_functions/file.rs:150 e :220, insieme a buffered_read_opt a :501 e detect_stream_type. Determina se il probing può far avanzare gli input e quale implementazione possiede il contatore condiviso. Il lavoro è completato quando il comportamento scelto è esplicito e il trace non fa più avanzare current_file due volte né salta gli input.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Split out from #2343, which made the symptom memory-safe without addressing the cause.
What happens
switch_to_next_file() advances current_file, then calls open(). That call reaches buffered_read_opt(), which calls switch_to_next_file() again when binary_concat is set — and that nested call advances current_file a second time.
Confirmed with a hardware watchpoint on a single-file run:
GUARD: current_file=0 num_input_files=1
BEFORE open: current_file=0
AFTER open: current_file=1 <-- advanced inside open()
with the mutation occurring here:
#0 ccx_rust::file_functions::file::switch_to_next_file (file.rs:220) <-- current_file += 1
#1 ccx_rust::file_functions::file::buffered_read_opt (file.rs:501)
#2 ccx_rust::demuxer::stream_functions::detect_stream_type
#3 ccx_rust::demuxer::common_types::CcxDemuxer::open
#4 ccxr_demuxer_open → ccx_demuxer_open (ccx_demuxer.c:62)
#5 switch_to_next_file (file_functions.c:181) <-- the outer call
So the outer call is an unwitting re-entrant caller of itself, across the C/Rust boundary, sharing one mutable counter.
Why it matters beyond the crash
#2343 stopped the out-of-bounds read by holding the filename across open() instead of re-indexing afterwards. The double advance itself is untouched, and it still means:
current_fileno longer identifies the file being processed onceopen()returns- with several inputs, entries can be stepped over: each outer iteration consumes two increments, so which files actually get opened depends on how many times the nested path fires
- two implementations of the same function —
file_functions.c:116andsrc/rust/src/file_functions/file.rs:150— are both live, both mutate the same state, and neither expects the other
A caller cannot currently tell whether current_file means "the file I am opening" or "the file the nested call moved on to". That ambiguity is the actual defect.
Worth deciding
- Should
detect_stream_type's probing read be able to switch input files at all? Advancing the input list while establishing what the current file is looks wrong regardless of the index bug. - Should the C
switch_to_next_file()remain, given the Rust port is what runs underDISABLE_RUST-off builds? Two live copies of this logic is how the identical stale-index bug came to exist in both.
Reproducing
The watchpoint trace above comes from:
gdb --args ./ccextractor sample.rcwt --out=webvtt --timestamp-map -o out.vtt
break file_functions.c:181
run
watch ctx->current_file
continue
The 153-byte RCWT sample from #2342 is enough; no special input is needed.
- Lingua principale
- C
- Stelle
- 905
- Fork
- 596
- Merge medio
- 4g 5h
- PR unite (30g)
- 33
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di CCExtractor/ccextractor
-
[BUG] Filename sequence expansion (`+`) panics on numeric values exceeding `i32::MAX`Forse già presa @muntasir-396 l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
CCExtractor/ccextractor#2402 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
CCExtractor/ccextractor#2398 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 62/100
CCExtractor/ccextractor#2379 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
--tpages-all extracts less than --tpageForse già presa @SajalDevX l’ha presa 24 giorni fa. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 65/100
CCExtractor/ccextractor#2355 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
CCExtractor/ccextractor#2317 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di CCExtractor/ccextractor
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
FujiNetWIFI/fujinet-firmware#2079 ·
I maintainer di solito rispondono entro 1 giorno
-
bug Official Image release/25.12 Supported Device target/kirkwood
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
area/archive bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
DarkFlippers/qUnleashed#374 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 84/100
VirusTotal/yara#2255 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100