Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

switch_to_next_file() re-enters itself through open(), advancing current_file twice

Chiusa
#2,344 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

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
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c, rust
Ambito
backend

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_file no longer identifies the file being processed once open() 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:116 and src/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

  1. 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.
  2. Should the C switch_to_next_file() remain, given the Rust port is what runs under DISABLE_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

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di CCExtractor/ccextractor

Tutte le issue di CCExtractor/ccextractor

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.