View Bug Details

IDProjectCategoryView StatusLast Update
0000766DCP-o-matic[All Projects] Bugspublic2016-07-04 14:13
Reporterrobn 
Assigned Tocarl 
PriorityhighSeveritycrashReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOSFedoraOS Version22
Product Version2.5.0 
Target VersionFixed in Version 
Summary0000766: Burned-in subtitles from specific .srt file lead to excessive memory consumption
DescriptionI had problems with rendering a DCP for a certain film:
DCP-o-matic would always crash after several hours.

I narrowed the problem down to the .srt subtitle file used in combination
with burned-in subtitles. Even when I edit the subtitle file and only
leave the first 5 subtitles in, the problems persists. This very short
"demo.srt" is uploaded with this report.

The only thing special I can see about the demo.srt file
is that "file demo.srt" says:

    UTF-8 Unicode (with BOM) text

This BOM thing corresponds to 2 bytes (FEFF) at the start of the file :

    https://en.wikipedia.org/wiki/Byte_order_mark

The subtitles are displayed OK in the preview window, and the
subtitles are rendered OK in the result. The only problem is
the huge amount of memory it takes ..
Steps To Reproduce- use any video content
- use the small "demo.srt" subtitle file
- configure "burned-in" subtitles
- start the DCP job

- watch the memory consumption of the DCP-o-matic grow unbounded.
  Eventually when all free virtual memory is used the kernel will
  kill the DCP-o-matic process if your content is long enough or your
  swap & memory small enough.
TagsNo tags attached.
Estimated work requiredAverage

Relationships

Activities

robn

2015-11-29 04:49

reporter  

demo.srt (339 bytes)

robn

2015-11-29 04:57

reporter   ~0001019

I tested with v2.5.11 but had the problem with an earlier version too (2.5.8 ?)

carl

2015-11-29 16:49

administrator   ~0001020

Please could you try 2.5.12 as there is a speculative fix for this.

robn

2015-11-29 21:55

reporter   ~0001021

Yes, 2.5.12 seems to fix the problem, thanks!

But I still don't understand why the problem was only with
the supplied subtitle file while any other .srt I tried did
*not* result in the uncontrolled memory usage ..

carl

2015-11-29 22:21

administrator   ~0001022

Yes, that is very strange. The bug should have manifested with any burn in. Let me know if you have further problems, and thanks for the detective work.

Bug History

Date Modified Username Field Change
2015-11-29 04:49 robn New Bug
2015-11-29 04:49 robn File Added: demo.srt
2015-11-29 04:57 robn Note Added: 0001019
2015-11-29 16:49 carl Note Added: 0001020
2015-11-29 16:49 carl Assigned To => carl
2015-11-29 16:49 carl Status new => feedback
2015-11-29 21:55 robn Note Added: 0001021
2015-11-29 21:55 robn Status feedback => assigned
2015-11-29 22:21 carl Note Added: 0001022
2015-11-29 22:21 carl Status assigned => resolved
2015-11-29 22:21 carl Resolution open => fixed