starred/ccextractor
1
0
Fork 0
mirror of https://github.com/CCExtractor/ccextractor.git synced 2026-02-04 05:44:53 +00:00
Code Issues 1.5k Packages Projects Releases 20 Wiki Activity

[PR #478] Fixed memory leaks #1294

New Issue
Open
opened 2026-01-29 17:00:55 +00:00 by claunia · 0 comments
claunia commented 2026-01-29 17:00:55 +00:00
Owner
Copy Link

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

State: closed
Merged: Yes

https://codein.withgoogle.com/dashboard/task-instances/5086033567809536/

Firstly you must make project after changes in code. Go to project folder and run cmake src and then make.
Run valgrind --leak-check=yes ./ccextractor [args].

If we run without arguments, then OK - no leaks are possible

==3145== 
==3145== HEAP SUMMARY:
==3145==     in use at exit: 0 bytes in 0 blocks
==3145==   total heap usage: 2 allocs, 2 frees, 1,576 bytes allocated
==3145== 
==3145== All heap blocks were freed -- no leaks are possible
==3145== 
==3145== For counts of detected and suppressed errors, rerun with: -v
==3145== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Run with random file valgring --leak-check=yes ./ccextractor /home/izaron/video/itunes.m4v. Oops, the lake of bytes lost in third blocks :(

==3238== 
==3238== HEAP SUMMARY:
==3238==     in use at exit: 90,403 bytes in 1,844 blocks
==3238==   total heap usage: 3,798 allocs, 1,954 frees, 27,856,944 bytes allocated
==3238== 
==3238== 5 bytes in 1 blocks are definitely lost in loss record 1 of 4
==3238==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3238==    by 0x53F2A59: strdup (strdup.c:42)
==3238==    by 0x4320B5: get_file_extension (utility.c:495)
==3238==    by 0x44B528: init_libraries (lib_ccx.c:165)
==3238==    by 0x42FD34: main (ccextractor.c:73)
==3238== 
==3238== 880 bytes in 1 blocks are definitely lost in loss record 2 of 4
==3238==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3238==    by 0x4551A5: ccx_decoders_xds_init_library (ccx_decoders_xds.c:131)
==3238==    by 0x44CE8D: init_cc_decode (ccx_decoders_common.c:361)
==3238==    by 0x44BA84: update_decoder_list (lib_ccx.c:272)
==3238==    by 0x44DBB6: processmp4 (mp4.c:295)
==3238==    by 0x430176: main (ccextractor.c:228)
==3238== 
==3238== 89,518 (29,472 direct, 60,046 indirect) bytes in 921 blocks are definitely lost in loss record 4 of 4
==3238==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3238==    by 0x48CA55: gf_isom_sample_new (isom_read.c:75)
==3238==    by 0x48EC71: gf_isom_get_sample (isom_read.c:1082)
==3238==    by 0x44E0BC: processmp4 (mp4.c:402)
==3238==    by 0x430176: main (ccextractor.c:228)
==3238== 
==3238== LEAK SUMMARY:
==3238==    definitely lost: 30,357 bytes in 923 blocks
==3238==    indirectly lost: 60,046 bytes in 921 blocks
==3238==      possibly lost: 0 bytes in 0 blocks
==3238==    still reachable: 0 bytes in 0 blocks
==3238==         suppressed: 0 bytes in 0 blocks
==3238== 
==3238== For counts of detected and suppressed errors, rerun with: -v
==3238== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)

But after exploring, only 2 lines cut down third block

free(sample->data);
free(sample);

And so on.

I checked the files with formats ts, mp4, mp4, vob on all types of subtitles and options. In the case of memory leaks, I fixed it. It took me a long time, because the slightest mistake led to a crash. The hardest thing was to fix raw format, seems like there are a bug.
In all cases I had 0 errors.

**Original Pull Request:** https://github.com/CCExtractor/ccextractor/pull/478 **State:** closed **Merged:** Yes --- [https://codein.withgoogle.com/dashboard/task-instances/5086033567809536/](url) Firstly you must make project after changes in code. Go to project folder and run `cmake src` and then `make`. Run `valgrind --leak-check=yes ./ccextractor [args]`. If we run without arguments, then OK - no leaks are possible ``` ==3145== ==3145== HEAP SUMMARY: ==3145== in use at exit: 0 bytes in 0 blocks ==3145== total heap usage: 2 allocs, 2 frees, 1,576 bytes allocated ==3145== ==3145== All heap blocks were freed -- no leaks are possible ==3145== ==3145== For counts of detected and suppressed errors, rerun with: -v ==3145== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ``` Run with random file `valgring --leak-check=yes ./ccextractor /home/izaron/video/itunes.m4v`. Oops, the lake of bytes lost in third blocks :( ``` ==3238== ==3238== HEAP SUMMARY: ==3238== in use at exit: 90,403 bytes in 1,844 blocks ==3238== total heap usage: 3,798 allocs, 1,954 frees, 27,856,944 bytes allocated ==3238== ==3238== 5 bytes in 1 blocks are definitely lost in loss record 1 of 4 ==3238== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3238== by 0x53F2A59: strdup (strdup.c:42) ==3238== by 0x4320B5: get_file_extension (utility.c:495) ==3238== by 0x44B528: init_libraries (lib_ccx.c:165) ==3238== by 0x42FD34: main (ccextractor.c:73) ==3238== ==3238== 880 bytes in 1 blocks are definitely lost in loss record 2 of 4 ==3238== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3238== by 0x4551A5: ccx_decoders_xds_init_library (ccx_decoders_xds.c:131) ==3238== by 0x44CE8D: init_cc_decode (ccx_decoders_common.c:361) ==3238== by 0x44BA84: update_decoder_list (lib_ccx.c:272) ==3238== by 0x44DBB6: processmp4 (mp4.c:295) ==3238== by 0x430176: main (ccextractor.c:228) ==3238== ==3238== 89,518 (29,472 direct, 60,046 indirect) bytes in 921 blocks are definitely lost in loss record 4 of 4 ==3238== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3238== by 0x48CA55: gf_isom_sample_new (isom_read.c:75) ==3238== by 0x48EC71: gf_isom_get_sample (isom_read.c:1082) ==3238== by 0x44E0BC: processmp4 (mp4.c:402) ==3238== by 0x430176: main (ccextractor.c:228) ==3238== ==3238== LEAK SUMMARY: ==3238== definitely lost: 30,357 bytes in 923 blocks ==3238== indirectly lost: 60,046 bytes in 921 blocks ==3238== possibly lost: 0 bytes in 0 blocks ==3238== still reachable: 0 bytes in 0 blocks ==3238== suppressed: 0 bytes in 0 blocks ==3238== ==3238== For counts of detected and suppressed errors, rerun with: -v ==3238== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0) ``` But after exploring, only 2 lines cut down third block ``` free(sample->data); free(sample); ``` And so on. I checked the files with formats ts, mp4, mp4, vob on all types of subtitles and options. In the case of memory leaks, I fixed it. It took me a long time, because the slightest mistake led to a crash. The hardest thing was to fix raw format, seems like there are a bug. In all cases I had 0 errors.
claunia added the pull-request label 2026-01-29 17:00:55 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
CEA-708
difficulty: easy
difficulty: hard
difficulty: medium
DTMB
DVB
enhancement
enhancement
Flutter GUI
GCI19
good-first-task
GSoC 2021
GSOC-2023
GSOC-2023
GSOC-2023
GSoC-related
Hacktoberfest
HardsubX
help wanted
invalid
JokerTV
Mac / OSX
more-info-needed
needs-commercial-sponsor
needs-commercial-sponsor
needs-commercial-sponsor
needs-confirmation-of-being-broken
OCR
pull-request
Mirrored from GitHub Pull Request
 Python
regression
Rust
teletext
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/ccextractor#1294
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?