Skip to content

fix: Refactor checks for manifest data when binding for c2pa_reader_with_manifest_data_and_stream is used#287

Merged
tmathern merged 2 commits into
mainfrom
mathern/118-c2pa_reader_with_manifest_data_and_stream
Jun 22, 2026
Merged

fix: Refactor checks for manifest data when binding for c2pa_reader_with_manifest_data_and_stream is used#287
tmathern merged 2 commits into
mainfrom
mathern/118-c2pa_reader_with_manifest_data_and_stream

Conversation

@tmathern

@tmathern tmathern commented Jun 22, 2026

Copy link
Copy Markdown
Collaborator

Changes in this pull request

  • Refactor manifest check on top of constructor for binding of c2pa_reader_with_manifest_data_and_stream (binding was already there, this improve on testing and does a refactor)
  • Refactor benchmark checks to only fail on leaks detection
  • Refactor tests for sidecars in their own test class
  • Added benchmark for sidecar file reading
Screenshot 2026-06-21 at 8 44 16 PM

Checklist

  • This PR represents a single feature, fix, or change.
  • All applicable changes have been documented.
  • Any TO DO items (or similar) have been entered as GitHub issues and the link to that issue has been included in a comment.

@tmathern tmathern requested a review from gpeacock June 22, 2026 04:56
@tmathern tmathern self-assigned this Jun 22, 2026
@tmathern tmathern changed the title fix: Refactor fix: Refactor checks for manifest data when binding for c2pa_reader_with_manifest_data_and_stream is used Jun 22, 2026
Comment thread tests/perf/baseline.json
"leaked_bytes": 3210242,
"total_allocations": 111383
},
"reader_manifest_data_context": {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

quite a leap here in peak_bytes and total_allocations, do you know why?

Comment thread tests/perf/run_profile.py

if baseline and name in baseline:
b = baseline[name]
# Only leaked_bytes gates the run. It is the leak signal and is

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this makes we wonder if we should expose an API for c_ffi leaked bytes. But I'm not sure exactly how that would work.

@gpeacock gpeacock left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Were we having leaks here? How did you know about them?

@tmathern

tmathern commented Jun 22, 2026

Copy link
Copy Markdown
Collaborator Author

Were we having leaks here? How did you know about them?

Yes, we did have one leak recently in c2pa-python in general. A Builder handle which was not released when it should. Accumulated 49 bytes over time on each Builder instance.

So I've been adding scenarios since then when I make change to make sure heap usage stays flat.

@tmathern tmathern merged commit 179a0dc into main Jun 22, 2026
26 checks passed
@tmathern tmathern deleted the mathern/118-c2pa_reader_with_manifest_data_and_stream branch June 22, 2026 20:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants