Uploading corrupt media with the FFmpeg thumbnailing backend causes a corrupted "thread 0" to be created #205

New Issue

ChristopherCormier · 2021-04-15T21:24:41Z

2021-04-15 21:24:41 +00:00

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.

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.

tslocum referenced this issue from a commit

2021-04-16 04:39:15 +00:00

Detect failure to create a thumbnail for non-video uploads

tslocum closed this issue

2021-04-16 04:39:15 +00:00

Sign in to join this conversation.