Uploading corrupt media with the FFmpeg thumbnailing backend causes a corrupted "thread 0" to be created #205
This is a very strange issue, but one that is likely reproducible more broadly than the specific instance in which I've encountered it. I have a corrupted JPG file on my PC that is identified correctly by FFmpeg as a JPG file, but it causes warnings and errors and ultimately fails to decode. Some other libraries will successfully decode it, but use many gigabytes of RAM in the process, so it's a "handle with caution" kind of file.
Whenever I upload it to TinyIB, it first shows a series of errors as shown here: https://i.imgur.com/MlZcA9s.png
TinyIB then proceeds to create a res/0.html file which renders as an extremely fucked up version of the index. This corrupted thread does not appear on the index or the catalog, even after a full rebuild. Trying to upload the image a second time will redirect you back to res/0.html again, with no changes.
For the purpose of reproducing it, this is the file I've used. I've contained the corrupted JPG in a 7z archive as sites generally reject it when uploaded directly: https://files.catbox.moe/5vb0ag.7z
With the other backends, ImageMagick will properly reject it and deliver a "Could not create thumbnail" message, which is the ideal. PHP GD will use an absurd amount of RAM until it's terminated by the OOM killer and produces an ugly error, which isn't great either but it doesn't end up creating the thread or otherwise causing any harm.
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?