[PR #2063] [FIX] Guard against NULL timing context when reporting decoder statistics #2874

New Issue

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

claunia commented

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

📋 Pull Request Information

Original PR: https://github.com/CCExtractor/ccextractor/pull/2063
Author: @hridyasadanand
Created: 1/26/2026
Status: 🔄 Open

Base: master ← Head: guard-null-timing-report

📝 Commits (3)

4e4cea5 Guard against NULL timing context in decoder reporting
f17a5e1 format: apply clang-format
a0e5a4e ci: retrigger workflows

📊 Changes

1 file changed (+3 additions, -0 deletions)

View changed files

📝 src/ccextractor.c (+3 -0)

📄 Description

[FIX] Guard against NULL timing context when reporting decoder statistics

In raising this pull request, I confirm the following (please check boxes):

I have read and understood the contributors guide.
I have checked that another pull request for this purpose does not exist.
I have considered, and confirmed that this submission will be valuable to others.
I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
I give this submission freely, and claim no ownership to its content.
I have mentioned this change in the changelog.

My familiarity with the project is as follows (check one):

I have never used CCExtractor.
I have used CCExtractor just a couple of times.
I absolutely love CCExtractor, but have not contributed previously.
I am an active contributor to CCExtractor.

Summary

This PR adds a defensive null check for dec_ctx->timing in the decoder reporting loop at the end of start_ccx().

Under certain execution paths, decoder contexts present in ctx->dec_ctx_head may not have an associated timing context. The current code assumes timing is always present and unconditionally dereferences dec_ctx->timing, which can lead to undefined behavior or crashes.

This change safely skips such decoder entries during reporting only.

Problem Description

The reporting loop in start_ccx() assumes that every decoder in ctx->dec_ctx_head has a valid timing structure.

While decoders created via init_cc_decode() always initialize timing, decoder contexts created via copy_decoder_context() explicitly set timing = NULL. These copied decoder contexts may still be present in dec_ctx_head, making the assumption invalid.

Fix

Add a simple guard before accessing timing fields:

if (!dec_ctx->timing)
    continue;

---

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

## 📋 Pull Request Information **Original PR:** https://github.com/CCExtractor/ccextractor/pull/2063 **Author:** [@hridyasadanand](https://github.com/hridyasadanand) **Created:** 1/26/2026 **Status:** 🔄 Open **Base:** `master` ← **Head:** `guard-null-timing-report` --- ### 📝 Commits (3) - [`4e4cea5`](https://github.com/CCExtractor/ccextractor/commit/4e4cea5b0309ed1458ae9f903468cd231e566cdd) Guard against NULL timing context in decoder reporting - [`f17a5e1`](https://github.com/CCExtractor/ccextractor/commit/f17a5e145b0a552d5688b42ab1b2ec8308e8a86c) format: apply clang-format - [`a0e5a4e`](https://github.com/CCExtractor/ccextractor/commit/a0e5a4e7f74ae3f7261e47d52a0c714a3d370323) ci: retrigger workflows ### 📊 Changes **1 file changed** (+3 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `src/ccextractor.c` (+3 -0) </details> ### 📄 Description [FIX] Guard against NULL timing context when reporting decoder statistics In raising this pull request, I confirm the following (please check boxes): - [x] I have read and understood the contributors guide. - [x] I have checked that another pull request for this purpose does not exist. - [x] I have considered, and confirmed that this submission will be valuable to others. - [x] I accept that this submission may not be used, and the pull request closed at the will of the maintainer. - [x] I give this submission freely, and claim no ownership to its content. - [ ] I have mentioned this change in the changelog. My familiarity with the project is as follows (check one): - [ ] I have never used CCExtractor. - [x] I have used CCExtractor just a couple of times. - [ ] I absolutely love CCExtractor, but have not contributed previously. - [ ] I am an active contributor to CCExtractor. --- ### Summary This PR adds a defensive null check for dec_ctx->timing in the decoder reporting loop at the end of start_ccx(). Under certain execution paths, decoder contexts present in ctx->dec_ctx_head may not have an associated timing context. The current code assumes timing is always present and unconditionally dereferences dec_ctx->timing, which can lead to undefined behavior or crashes. This change safely skips such decoder entries during reporting only. ### Problem Description The reporting loop in start_ccx() assumes that every decoder in ctx->dec_ctx_head has a valid timing structure. While decoders created via init_cc_decode() always initialize timing, decoder contexts created via copy_decoder_context() explicitly set timing = NULL. These copied decoder contexts may still be present in dec_ctx_head, making the assumption invalid. ### Fix Add a simple guard before accessing timing fields: ```c if (!dec_ctx->timing) continue; --- <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:24:22 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/ccextractor#2874