intermittent crash woes

[snorwood]

Weird intermittent problem:

On a specific input file, DCP-o-Matic will often but not always crash for me while encoding the DCP. Usually, this happens at the beginning of the process (first few minutes), but sometimes the DCP will be made without errors.

Tested and confirmed with 2.16.69 and 2.16.35 on Windows 10 (fully patched to current levels as of 11/30). I have tested it with the same version on Linux (Rocky 8) on the same hardware without crashes, but it does happen on 2.16.35 on Linux (same problem, not always repeatable). I had coredumps disabled on Linux. The Windows error is as follows:

Faulting application name: dcpomatic2.exe, version: 0.0.0.0, time stamp: 0x65648ebb
Faulting module name: libopenjp2.dll, version: 0.0.0.0, time stamp: 0x65648dc8
Exception code: 0xc0000005
Fault offset: 0x0000000000038897
Faulting process id: 0x4308
Faulting application start time: 0x01da23396e56badc
Faulting application path: C:\Program Files\DCP-o-matic 2\bin\dcpomatic2.exe
Faulting module path: C:\Program Files\DCP-o-matic 2\bin\libopenjp2.dll
Report Id: b684a927-eae4-4d2e-8497-bfd34b9782e0
Faulting package full name:
Faulting package-relative application ID:

dcpomatic2.exe
0.0.0.0
65648ebb
libopenjp2.dll
0.0.0.0
65648dc8
c0000005
0000000000038897
4308
01da23396e56badc
C:\Program Files\DCP-o-matic 2\bin\dcpomatic2.exe
C:\Program Files\DCP-o-matic 2\bin\libopenjp2.dll
b684a927-eae4-4d2e-8497-bfd34b9782e0


The input file in question is from the Internet Archive:

https://archive.org/download/y-2-mate.i ... 939.ia.mp4

I would not rule out a problem with the input file, although it plays fine and the DCP can sometimes be made successfully.

To reproduce:
Create new project, add the above file, route both left and right audio channels to center, and make DCP. (This might happen without the audio routing changes; I have not tested this).

Hardware in question is an Intel 13900k, 32GB RAM, plenty of SSD storage, etc. Nothing unusual.

Thoughts? If it is helpful, I will try again to reproduce this on Linux and get a core dump. I can also try it on a clean Windows install if that is helpful in some way.

Thanks.

[Carsten]

Would be interesting to try recompressing this MP4 using handbrake and check if the new file does not cause issues. Not sure wether it's actually the input file if openjpeg crashes. But maybe the decoder delivers a bad image to the J2C encoder. MP4 is very complex.

[carl]

I'll try and reproduce it here. If I don't get anywhere perhaps we can get a core dump and then a backtrace from Linux. I made a bug in the tracker.

[snorwood]

I managed to get this to crash again. The coredump is here:

http://s3.amazonaws.com/snorwood/core-d ... c2-4910.gz

This was with 2.16.78-1 on Rocky 8.

I am starting to wonder if this is the Intel 13th gen crash problem and unrelated to DCP-o-Matic. I am using a 13900k, but completely stock without any overclocking stuff enabled.

[Carsten]

If that's the reason, the problem will most likely occur with other content of similar parameters as well?

[snorwood]

It does happen with different content, and not consistently. I have a case open with Intel now. We shall see what happens.

[carl]

Thanks for the backtrace - I'll take a look as soon as I can.

[Carsten]

Just read an article about the Intel CPU problems, and it seems currently Intel is advising mainboard manufacturers so set more conservative chipset timing parameters to prevent the issue.

[snorwood]

Yes, I think that the next step is to try the new "Intel defaults" BIOS that Asus recently released.

DCP-o-Matic is the only program that crashes like this for me, but I am not running anything else that hammers the CPU this much, either. Reducing the number of threads seems to improve stability, which is leading me toward thinking that this is an Intel issue. Unfortunately, Intel is not being super-helpful about diagnosing this (yet, anyway).

[snorwood]

Update: it was an Intel problem. They replaced the processor (after a horrid two-month RMA process) and all seems well now.