OCR - Use of uninitialised value (strlen) #256

Closed
opened 2026-01-29 16:39:06 +00:00 by claunia · 2 comments
Owner

Originally created by @cfsmp3 on GitHub (Jan 24, 2017).

Originally assigned to: @Abhinav95 on GitHub.

More than one bit level marked: 60
More than one bit level marked: 60
Invalid clut depth 0xe!
==26875== Use of uninitialised value of size 8
==26875== at 0x4C30F62: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26875== by 0x428FF0: paraof_ocrtext (ocr.c:753)
==26875== by 0x449B19: reformat_cc_bitmap_through_sentence_buffer (ccx_encoders_splitbysentence.c:764)
==26875== by 0x42D2DD: encode_sub (ccx_encoders_common.c:1065)
==26875== by 0x441264: dvbsub_decode (dvb_subtitle_decoder.c:1651)
==26875== by 0x45CECD: process_data (general_loop.c:650)
==26875== by 0x45DC75: general_loop (general_loop.c:960)
==26875== by 0x4070FF: main (ccextractor.c:222)
==26875==
==26875== Invalid read of size 1
==26875== at 0x4C30F62: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26875== by 0x428FF0: paraof_ocrtext (ocr.c:753)
==26875== by 0x449B19: reformat_cc_bitmap_through_sentence_buffer (ccx_encoders_splitbysentence.c:764)
==26875== by 0x42D2DD: encode_sub (ccx_encoders_common.c:1065)
==26875== by 0x441264: dvbsub_decode (dvb_subtitle_decoder.c:1651)
==26875== by 0x45CECD: process_data (general_loop.c:650)
==26875== by 0x45DC75: general_loop (general_loop.c:960)
==26875== by 0x4070FF: main (ccextractor.c:222)
==26875== Address 0x400000005 is not stack'd, malloc'd or (recently) free'd
==26875==
==26875==
==26875== Process terminating with default action of signal 11 (SIGSEGV)
==26875== Access not within mapped region at address 0x400000005
==26875== at 0x4C30F62: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26875== by 0x428FF0: paraof_ocrtext (ocr.c:753)
==26875== by 0x449B19: reformat_cc_bitmap_through_sentence_buffer (ccx_encoders_splitbysentence.c:764)
==26875== by 0x42D2DD: encode_sub (ccx_encoders_common.c:1065)
==26875== by 0x441264: dvbsub_decode (dvb_subtitle_decoder.c:1651)
==26875== by 0x45CECD: process_data (general_loop.c:650)
==26875== by 0x45DC75: general_loop (general_loop.c:960)
==26875== by 0x4070FF: main (ccextractor.c:222)
==26875== If you believe this happened as a result of a stack
==26875== overflow in your program's main thread (unlikely but
==26875== possible), you can try to increase the size of the
==26875== main thread stack using the --main-stacksize= flag.
==26875== The main thread stack size used in this run was 8388608.

Originally created by @cfsmp3 on GitHub (Jan 24, 2017). Originally assigned to: @Abhinav95 on GitHub. More than one bit level marked: 60 More than one bit level marked: 60 Invalid clut depth 0xe! ==26875== Use of uninitialised value of size 8 ==26875== at 0x4C30F62: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==26875== by 0x428FF0: paraof_ocrtext (ocr.c:753) ==26875== by 0x449B19: reformat_cc_bitmap_through_sentence_buffer (ccx_encoders_splitbysentence.c:764) ==26875== by 0x42D2DD: encode_sub (ccx_encoders_common.c:1065) ==26875== by 0x441264: dvbsub_decode (dvb_subtitle_decoder.c:1651) ==26875== by 0x45CECD: process_data (general_loop.c:650) ==26875== by 0x45DC75: general_loop (general_loop.c:960) ==26875== by 0x4070FF: main (ccextractor.c:222) ==26875== ==26875== Invalid read of size 1 ==26875== at 0x4C30F62: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==26875== by 0x428FF0: paraof_ocrtext (ocr.c:753) ==26875== by 0x449B19: reformat_cc_bitmap_through_sentence_buffer (ccx_encoders_splitbysentence.c:764) ==26875== by 0x42D2DD: encode_sub (ccx_encoders_common.c:1065) ==26875== by 0x441264: dvbsub_decode (dvb_subtitle_decoder.c:1651) ==26875== by 0x45CECD: process_data (general_loop.c:650) ==26875== by 0x45DC75: general_loop (general_loop.c:960) ==26875== by 0x4070FF: main (ccextractor.c:222) ==26875== Address 0x400000005 is not stack'd, malloc'd or (recently) free'd ==26875== ==26875== ==26875== Process terminating with default action of signal 11 (SIGSEGV) ==26875== Access not within mapped region at address 0x400000005 ==26875== at 0x4C30F62: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==26875== by 0x428FF0: paraof_ocrtext (ocr.c:753) ==26875== by 0x449B19: reformat_cc_bitmap_through_sentence_buffer (ccx_encoders_splitbysentence.c:764) ==26875== by 0x42D2DD: encode_sub (ccx_encoders_common.c:1065) ==26875== by 0x441264: dvbsub_decode (dvb_subtitle_decoder.c:1651) ==26875== by 0x45CECD: process_data (general_loop.c:650) ==26875== by 0x45DC75: general_loop (general_loop.c:960) ==26875== by 0x4070FF: main (ccextractor.c:222) ==26875== If you believe this happened as a result of a stack ==26875== overflow in your program's main thread (unlikely but ==26875== possible), you can try to increase the size of the ==26875== main thread stack using the --main-stacksize= flag. ==26875== The main thread stack size used in this run was 8388608.
Author
Owner

@cfsmp3 commented on GitHub (Jan 26, 2017):

GSoC qualification: This issue gives 3 points.

@cfsmp3 commented on GitHub (Jan 26, 2017): GSoC qualification: This issue gives 3 points.
Author
Owner

@cfsmp3 commented on GitHub (Jan 30, 2017):

This one is going to be hard to conclusively solve because there's no sample - it was a UDP stream, and it was running on valgrind (which always means data loss since the valgrind'ed version can't keep up with the data).

Anyway I did what I could to emulate the problem (by forcing the code branch that triggers that CLUT depth problem).

The original dvbsub_parse_clut_segment() always return 0 (including on that error), even though the caller expects -1 in there's problems and then bails out. So I've changed the return in that case to -1 and tested a bit by forcing the branch with the debugger.

I cannot be 100% sure it's solved but makes more sense.

I'm not closing this until @Abhinav95 takes a quick look though.

@cfsmp3 commented on GitHub (Jan 30, 2017): This one is going to be hard to conclusively solve because there's no sample - it was a UDP stream, and it was running on valgrind (which always means data loss since the valgrind'ed version can't keep up with the data). Anyway I did what I could to emulate the problem (by forcing the code branch that triggers that CLUT depth problem). The original dvbsub_parse_clut_segment() always return 0 (including on that error), even though the caller expects -1 in there's problems and then bails out. So I've changed the return in that case to -1 and tested a bit by forcing the branch with the debugger. I cannot be 100% sure it's solved but makes more sense. I'm not closing this until @Abhinav95 takes a quick look though.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/ccextractor#256