starred/ccextractor
1
0
Fork 0
mirror of https://github.com/CCExtractor/ccextractor.git synced 2026-02-14 21:23:42 +00:00
Code Issues 1.5k Packages Projects Releases 20 Wiki Activity

UDP stream segfault #64

New Issue
Closed
opened 2026-01-29 16:34:15 +00:00 by claunia · 2 comments
claunia commented 2026-01-29 16:34:15 +00:00
Owner
Copy Link

Originally created by @okisseloff on GitHub (Jul 1, 2015).

I've finally cought a segfault with valgrind

==13192== Invalid write of size 1
==13192==    at 0x4C2A88A: memcpy (mc_replace_strmem.c:838)
==13192==    by 0x504ED9: write_section (ts_tables.c:419)
==13192==    by 0x4F1FF1: ts_readstream (ts_functions.c:325)
==13192==    by 0x4F257C: ts_getmoredata (ts_functions.c:486)
==13192==    by 0x507E1C: general_loop (general_loop.c:570)
==13192==    by 0x49E724: main (ccextractor.c:261)
==13192==  Address 0xffffffff8f2822d6 is not stack'd, malloc'd or (recently) free'd
==13192== 
==13192== 
==13192== Process terminating with default action of signal 11 (SIGSEGV)
==13192==  Access not within mapped region at address 0xFFFFFFFF8F2822D6
==13192==    at 0x4C2A88A: memcpy (mc_replace_strmem.c:838)
==13192==    by 0x504ED9: write_section (ts_tables.c:419)
==13192==    by 0x4F1FF1: ts_readstream (ts_functions.c:325)
==13192==    by 0x4F257C: ts_getmoredata (ts_functions.c:486)
==13192==    by 0x507E1C: general_loop (general_loop.c:570)
==13192==    by 0x49E724: main (ccextractor.c:261)
==13192==  If you believe this happened as a result of a stack
==13192==  overflow in your program's main thread (unlikely but
==13192==  possible), you can try to increase the size of the
==13192==  main thread stack using the --main-stacksize= flag.
==13192==  The main thread stack size used in this run was 8388608.
==13192== 
==13192== HEAP SUMMARY:
==13192==     in use at exit: 208,281,265 bytes in 421 blocks
==13192==   total heap usage: 4,910 allocs, 4,489 frees, 220,492,160 bytes allocated
==13192== 
==13192== LEAK SUMMARY:
==13192==    definitely lost: 1,845 bytes in 369 blocks
==13192==    indirectly lost: 0 bytes in 0 blocks
==13192==      possibly lost: 7,248 bytes in 6 blocks
==13192==    still reachable: 208,272,172 bytes in 46 blocks
==13192==         suppressed: 0 bytes in 0 blocks
==13192== Rerun with --leak-check=full to see details of leaked memory
==13192== 
==13192== For counts of detected and suppressed errors, rerun with: -v
==13192== Use --track-origins=yes to see where uninitialised values come from
==13192== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4)
Killed
Originally created by @okisseloff on GitHub (Jul 1, 2015). I've finally cought a segfault with valgrind ``` ==13192== Invalid write of size 1 ==13192== at 0x4C2A88A: memcpy (mc_replace_strmem.c:838) ==13192== by 0x504ED9: write_section (ts_tables.c:419) ==13192== by 0x4F1FF1: ts_readstream (ts_functions.c:325) ==13192== by 0x4F257C: ts_getmoredata (ts_functions.c:486) ==13192== by 0x507E1C: general_loop (general_loop.c:570) ==13192== by 0x49E724: main (ccextractor.c:261) ==13192== Address 0xffffffff8f2822d6 is not stack'd, malloc'd or (recently) free'd ==13192== ==13192== ==13192== Process terminating with default action of signal 11 (SIGSEGV) ==13192== Access not within mapped region at address 0xFFFFFFFF8F2822D6 ==13192== at 0x4C2A88A: memcpy (mc_replace_strmem.c:838) ==13192== by 0x504ED9: write_section (ts_tables.c:419) ==13192== by 0x4F1FF1: ts_readstream (ts_functions.c:325) ==13192== by 0x4F257C: ts_getmoredata (ts_functions.c:486) ==13192== by 0x507E1C: general_loop (general_loop.c:570) ==13192== by 0x49E724: main (ccextractor.c:261) ==13192== If you believe this happened as a result of a stack ==13192== overflow in your program's main thread (unlikely but ==13192== possible), you can try to increase the size of the ==13192== main thread stack using the --main-stacksize= flag. ==13192== The main thread stack size used in this run was 8388608. ==13192== ==13192== HEAP SUMMARY: ==13192== in use at exit: 208,281,265 bytes in 421 blocks ==13192== total heap usage: 4,910 allocs, 4,489 frees, 220,492,160 bytes allocated ==13192== ==13192== LEAK SUMMARY: ==13192== definitely lost: 1,845 bytes in 369 blocks ==13192== indirectly lost: 0 bytes in 0 blocks ==13192== possibly lost: 7,248 bytes in 6 blocks ==13192== still reachable: 208,272,172 bytes in 46 blocks ==13192== suppressed: 0 bytes in 0 blocks ==13192== Rerun with --leak-check=full to see details of leaked memory ==13192== ==13192== For counts of detected and suppressed errors, rerun with: -v ==13192== Use --track-origins=yes to see where uninitialised values come from ==13192== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4) Killed ```
claunia commented 2026-01-29 16:34:15 +00:00
Author
Owner
Copy Link

@cfsmp3 commented on GitHub (Jul 1, 2015):

Great catch :-) Anshul are you looking into this? If not, I can check it
out myself.

On Wed, Jul 1, 2015 at 1:00 PM, kisselef notifications@github.com wrote:

I've finally cought a segfault with valgrind

==13192== Invalid write of size 1
==13192== at 0x4C2A88A: memcpy (mc_replace_strmem.c:838)
==13192== by 0x504ED9: write_section (ts_tables.c:419)
==13192== by 0x4F1FF1: ts_readstream (ts_functions.c:325)
==13192== by 0x4F257C: ts_getmoredata (ts_functions.c:486)
==13192== by 0x507E1C: general_loop (general_loop.c:570)
==13192== by 0x49E724: main (ccextractor.c:261)
==13192== Address 0xffffffff8f2822d6 is not stack'd, malloc'd or (recently) free'd
==13192==
==13192==
==13192== Process terminating with default action of signal 11 (SIGSEGV)
==13192== Access not within mapped region at address 0xFFFFFFFF8F2822D6
==13192== at 0x4C2A88A: memcpy (mc_replace_strmem.c:838)
==13192== by 0x504ED9: write_section (ts_tables.c:419)
==13192== by 0x4F1FF1: ts_readstream (ts_functions.c:325)
==13192== by 0x4F257C: ts_getmoredata (ts_functions.c:486)
==13192== by 0x507E1C: general_loop (general_loop.c:570)
==13192== by 0x49E724: main (ccextractor.c:261)
==13192== If you believe this happened as a result of a stack
==13192== overflow in your program's main thread (unlikely but
==13192== possible), you can try to increase the size of the
==13192== main thread stack using the --main-stacksize= flag.
==13192== The main thread stack size used in this run was 8388608.
==13192==
==13192== HEAP SUMMARY:
==13192== in use at exit: 208,281,265 bytes in 421 blocks
==13192== total heap usage: 4,910 allocs, 4,489 frees, 220,492,160 bytes allocated
==13192==
==13192== LEAK SUMMARY:
==13192== definitely lost: 1,845 bytes in 369 blocks
==13192== indirectly lost: 0 bytes in 0 blocks
==13192== possibly lost: 7,248 bytes in 6 blocks
==13192== still reachable: 208,272,172 bytes in 46 blocks
==13192== suppressed: 0 bytes in 0 blocks
==13192== Rerun with --leak-check=full to see details of leaked memory
==13192==
==13192== For counts of detected and suppressed errors, rerun with: -v
==13192== Use --track-origins=yes to see where uninitialised values come from
==13192== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4)
Killed

—
Reply to this email directly or view it on GitHub
https://github.com/CCExtractor/ccextractor/issues/196.

@cfsmp3 commented on GitHub (Jul 1, 2015): Great catch :-) Anshul are you looking into this? If not, I can check it out myself. On Wed, Jul 1, 2015 at 1:00 PM, kisselef notifications@github.com wrote: > I've finally cought a segfault with valgrind > > ==13192== Invalid write of size 1 > ==13192== at 0x4C2A88A: memcpy (mc_replace_strmem.c:838) > ==13192== by 0x504ED9: write_section (ts_tables.c:419) > ==13192== by 0x4F1FF1: ts_readstream (ts_functions.c:325) > ==13192== by 0x4F257C: ts_getmoredata (ts_functions.c:486) > ==13192== by 0x507E1C: general_loop (general_loop.c:570) > ==13192== by 0x49E724: main (ccextractor.c:261) > ==13192== Address 0xffffffff8f2822d6 is not stack'd, malloc'd or (recently) free'd > ==13192== > ==13192== > ==13192== Process terminating with default action of signal 11 (SIGSEGV) > ==13192== Access not within mapped region at address 0xFFFFFFFF8F2822D6 > ==13192== at 0x4C2A88A: memcpy (mc_replace_strmem.c:838) > ==13192== by 0x504ED9: write_section (ts_tables.c:419) > ==13192== by 0x4F1FF1: ts_readstream (ts_functions.c:325) > ==13192== by 0x4F257C: ts_getmoredata (ts_functions.c:486) > ==13192== by 0x507E1C: general_loop (general_loop.c:570) > ==13192== by 0x49E724: main (ccextractor.c:261) > ==13192== If you believe this happened as a result of a stack > ==13192== overflow in your program's main thread (unlikely but > ==13192== possible), you can try to increase the size of the > ==13192== main thread stack using the --main-stacksize= flag. > ==13192== The main thread stack size used in this run was 8388608. > ==13192== > ==13192== HEAP SUMMARY: > ==13192== in use at exit: 208,281,265 bytes in 421 blocks > ==13192== total heap usage: 4,910 allocs, 4,489 frees, 220,492,160 bytes allocated > ==13192== > ==13192== LEAK SUMMARY: > ==13192== definitely lost: 1,845 bytes in 369 blocks > ==13192== indirectly lost: 0 bytes in 0 blocks > ==13192== possibly lost: 7,248 bytes in 6 blocks > ==13192== still reachable: 208,272,172 bytes in 46 blocks > ==13192== suppressed: 0 bytes in 0 blocks > ==13192== Rerun with --leak-check=full to see details of leaked memory > ==13192== > ==13192== For counts of detected and suppressed errors, rerun with: -v > ==13192== Use --track-origins=yes to see where uninitialised values come from > ==13192== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4) > Killed > > — > Reply to this email directly or view it on GitHub > https://github.com/CCExtractor/ccextractor/issues/196.
claunia commented 2026-01-29 16:34:16 +00:00
Author
Owner
Copy Link

@anshul1912 commented on GitHub (Jul 1, 2015):

Yes i am looking at it, this looked related to one of broken video. I might be able to solve it by tommarow.

@anshul1912 commented on GitHub (Jul 1, 2015): Yes i am looking at it, this looked related to one of broken video. I might be able to solve it by tommarow.
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
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#64
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?