Bug Report: libavcodec/ffmpeg crashes when explorer attemps to create folder icon for certain .avi's

Phew, generating that title was tough!

Anyway, if explorer's folder options does not specify "Always Show Icons, never Thumbnails" then simply having an .avi file whose frame rate happens to be non-integral and residing any directory (regardless of that directory's folder view format) produces the following error:



The "process" is one of Microsoft's myriad application (or dll function) launchers "dllhost.exe". The details of this particular instance being:

Process: C:\Windows\System32\dllhost.exe
Command Line: C:\Windows\system32\DllHost.exe /Processid:{AB8902B4-09CA-4BB6-B78D-A8F59079A8D5}
AutoStart Location: HKLM\System\CurrentControlSet\Services\COMSysApp

The above should be pretty clear but, just for those unfamiliar with everyday Windows apps, AppId "{AB8902B4-09CA-4BB6-B78D-A8F59079A8D5}" happens identify to our old friend "Thumbnail Cache Out of Proc Server" which is simply a "Thumbnail Cache Class Factory" whose "InprocServer32", should it be used, happens to be:

C:\Windows\system32\thumbcache.dll
[For the benefit of the computer illiterate and of course Linux/Mac/Ubuntu users who wouldn't know: just look under HKCR\{AB8902B4-09CA-4BB6-B78D-A8F59079A8D5}\InprocServer32 ]

But I'm not using the Inproc server of course, I'm using K-lite. So skipping lazily over to process explorer (yawn), and selecting the nearly-dead dllhost.exe process currently displaying an assertion dialog, I find (highlighted in the list of loaded modules):

C:\Windows\system32\icm32.dll

Which is probably of no technical use.

However just above that line is the following:
C:\Program Files\K-Lite Codec Pack\Icaros\IcarosThumbnailProvider.dll

And many other K-Lite dlls from the same folder also loaded into memory, though unfortunately none including the partial string "ffmpeg". Unfortunately the module identified in the assertion happens to be the executable file (not dllhost.exe thank God) instead of the module where the exception actually occurred.

So how do I know it's the ffmpeg lib crashing? Answer: Because I can use Google Search (search string: avidec.c).

However, looking at the assertion text itself I think it should be obvious that a comparison of exact equality between two variables related to time offsets and involving what I can only assume is a frame rate [time_base.num*((*ast2).rate)] and referring to an .avi whose frame rate happens to be 26.545 is pretty unlikely to come out "true".

Just thought I'd mention it. Because it crashed explorer and even the recycle bin could not be viewed without causing a crash. I managed to retrieve the file out of the recycle bin by enabling the folder option "Always Show Icons, never Thumbnails". I was going to create a sample, but I think you have enough info!

Thanks,
- Alan

Thanks for the detailed report.

The values in the comparison are rounded to whole numbers, so under normal circumstances it should not fail. It has to be something specific about that file that triggered a bug. Can you tell me where you got the file? That would be helpful for the developers of Icaros and FFmpeg to fix the problem.

You can enable/disable thumbnails at any time with the Codec Tweak Tool. That should be a useful tip in case you ever encounter a problematic file again.

There's nothing to creating such a file with Virtual Dub. Sometimes I have to do that as an intermediary step in re-synchronizing a video file where my conversion program has failed to take into account a variable frame rate .flv file. In fact, it almost always fails to create anything I can re-synchronize with the bizarre .flv's YouTube is producing nowadays.

But, if you like I'll create one for you when VDub is done with its current job.

If you want to do it yourself, just open up any .avi file in virtual dub, select "full processing mode" for audio and (I think) just direct stream copy for video.

Then go into the audio menu and select "Frame Rate" (I think! I can't access the program while it's encoding and I'm too much of a pussy to open a 2nd instance in case I lose 10 hours worth of encoding!). From there you can choose any frame rate you like, even non-integral ones and it will convert the .avi to have that frame rate.

If that doesn't work, an easy trick would be to use direct stream copy for both A and V, choose an avi file that's say 3 mins long and then for audio select "from another file". Then choose a different file that is slightly shorter. Save the resulting mixture and close the program.

Reopen the program and then as before with video "direct" and audio "full", go to "Frame Rate" and you can now check "change frame rate so audio and video durations match".

If the times are similar you will get a fractional frame rate outputted file. At that point all you need to do is view the folder and just click on the file once in explorer to cause the crash.

[Edited to add: I just noticed, and it may be relevant, that in this case since the fractional part is greater than 0.5, then depending on your rounding routine, it may round up or down. If rounding up vs. down matters, then an easy and reliable fix would be to always round in the same direction.]

[Edited again to add: If the fractional part is required to produce exact equality, then an even easier quick and reliable fix would be to work in units of frames per 1000 seconds. That is, just multiply everything by 1000 and then everything becomes integral again]

Okay, I just tried it with a short file and no crash. So I can only assume that this condition remains true up to a certain number of frames.

I am re-downloading the file that caused the fault. I'll attempt to reproduce the conditions that caused the crash and then make the resulting .avi available somehow.

Okay I have reproduced the bug. It was a two step process where I used the audio from an mp4 file (converted to mp3) from another source of the same video which I had in flv format and that I thought might synchronize with it. It didn't synchronize so I changed the frame rate. And the resulting file is the one that crashes. And any portion of it.

So I have prepared a zip file with a portion of that file that causes the crash. Uploading it to RapidShare ... it should be there in about 15 mins.

- Alan

Okay, here it is!

http://rapidshare.com/share/C974ECA93412975F0E933DB3794D1438

The developers of Icaros and FFmpeg have been notified. (please don't remove the sample)

I get no crash with Icaros at default settings (offset = 25%). But I was able to reproduce it with another application that uses libavformat.

To be totally honest, I have no idea know what Icaros is or stands for (although I haven't looked into it very closely) I was more interested in the fact that it was under the K-lite directory and that there was something to do with a thumbnail cache DLL in there and all of its DLLs were mapped into the memory space of the crashing module.

So, taking a totally wild guess, I pointed the finger there.

But as I said, the module identified was not the module wherein the exception occurred (I know that with 100% certainty because Microsoft would never ship a debug version because that's against their own deployment guidelines and explicitly prohibited in commercial products)

Although [speaking softly] I know as well with 100% certainty that some very large companies only ship debug versions of their software. Why? Because I worked for one!. But I won't name it! .

- Alan

Icaros is a shell extension for generating video thumbnails in Explorer. It uses libraries from FFmpeg for parsing/decoding.

Assertions can be present in release builds. There are no debug builds being used.

I beg to differ. Unless I am misreading the MSDN documentation (concerning debug reporting modes):


ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_vccrt/html/3ecc6a12-afdd-4242-b046-8187ff6d4b36.htm

********************************************
int _CrtSetReportMode(
  int reportType,
  int reportMode
);

Specifies the destination or destinations for a specific report type generated by _CrtDbgReport and any macros that call _CrtDbgReport, _CrtDbgReportW, such as _ASSERT, _ASSERTE Macros, _ASSERT, _ASSERTE Macros, _RPT, _RPTF, _RPTW, _RPTFW Macros, and _RPT, _RPTF, _RPTW, _RPTFW Macros (debug version only).


etc ...

Lastly:

Routine
_CrtSetReportMode    
Required header  
<crtdbg.h>
<errno.h>

Compatibility  
Windows 95, Windows 98, Windows 98 Second Edition, Windows Millennium Edition, Windows Millennium Edition, Windows NT 4.0, Windows 2000, Windows XP Home Edition, Windows XP Professional, Windows Server 2003

For more compatibility information, see Compatibility in the Introduction.

Libraries:
******* Debug versions of C Run-Time Libraries only. ***********

[emphasis mine]
-----------------------------

So in order to produce that message box, the debug versions of the runtime libraries had to be present and _DEBUG had to have been defined. Otherwise the required report mode could not be set and the dialog resource would not have been present.

[Edited to add: But I couldn't care less of course. In fact shipping the debug version is often essential where it is critical that the software behave with the highest level of stability]

You looked at the wrong docs. This is the correct one:
http://msdn.microsoft.com/en-us/library/9sb57dw4.aspx

The developer of Icaros was not able to reproduce the crash yet (with Icaros itself). But if the bug gets fixed in FFmpeg, it will automatically be fixed in Icaros and any other program that uses FFmpeg, such as VLC.

Taking from: (your link)

When the application is linked with a debug version of the run-time libraries, assert creates a message box with three buttons: Abort, Retry, and Ignore. If the user clicks Abort, the program aborts immediately. If the user clicks Retry, the debugger is called and the user can debug the program if just-in-time (JIT) debugging is enabled. If the user clicks Ignore, assert continues with its normal execution: creating the message box with the OK button. Note that clicking Ignore when an error condition exists can result in undefined behavior.

-------------------------

Of course it is a trivial matter to check what the meaning of the following line is:

The assert routine is available in both the release and debug versions of the C run-time libraries. Two other assertion macros, _ASSERT and _ASSERTE, are also available, but they only evaluate the expressions passed to them when the _DEBUG flag has been defined.

And the answer is that in fact the message box *does* come up provided NDEBUG is not defined.

So you are correct, and the documentation is misleading.

Why do they say:

When the application is linked with a debug version of the run-time libraries assert creates a message box with three buttons: Abort, Retry, and Ignore.

when the following is equally true:

When the application is not linked with a debug version of the run-time libraries assert creates a message box with three buttons: Abort, Retry, and Ignore.

?

My bad, but you can see how the documentation could lead one to believe that there is some connection between that dialog and the debug runtime libraries no?

It is probably because you have debugging tools installed. Then behavior is a bit different from normal. It may show a debug option, but that doesn't mean there are any debug symbols available for any of the loaded modules.

You seem to be using a rather old version of the codec pack. After investigation it turns out that the assertion in question was removed in the code that is used by Icaros.

The version says 2.1.0.0. I installed it on 03/27/2013 (just over a year ago I guess).

It seems to be working fine other than that rare instance. Is there an advantage to updating? I'm not in the habit of fixing things that aren't broken.

- Alan

[Edited to add: I'm quite serious about not installing updates just to keep up-2-date. In fact I haven't installed an update from Microsoft in over a year. I don't run any AV software either and I've disabled Windows Defender. But I do trust K-lite.]

Yes, there are certainly advantages to updating. It will obviously fix this particular problem. There are also many other fixes and improvements. Better performance and support for a few new formats, such as HEVC (the successor of H.264).

Admin wrote:It is probably because you have debugging tools installed. Then behavior is a bit different from normal. It may show a debug option, but that doesn't mean there are any debug symbols available for any of the loaded modules.

It shouldn't behave differently, or else how can you test your release builds? I'm using static linking so the RTL is glued into the .exe and I'm not including any debug information.

But ... I can test it out and see what's mapped into memory. My guess is nothing containing with the letters "crt".

comctl32.dll       C:\Windows\winsxs\.v6..\comctl32.dll 0x74890000 ASLR
uxtheme.dll        C:\Windows\System32\uxtheme.dll 0x746A0000 ASLR
usp10.dll          C:\Windows\System32\usp10.dll 0x77630000 ASLR
user32.dll         C:\Windows\System32\user32.dll 0x75EB0000 ASLR
shlwapi.dll        C:\Windows\System32\shlwapi.dll 0x77810000 ASLR
sechost.dll        C:\Windows\System32\sechost.dll 0x76230000 ASLR
rpcrt4.dll         C:\Windows\System32\rpcrt4.dll 0x77760000 ASLR
ole32.dll          C:\Windows\System32\ole32.dll 0x76880000 ASLR
ntdll.dll          C:\Windows\System32\ntdll.dll 0x77A80000 ASLR
msvcrt.dll         C:\Windows\System32\msvcrt.dll 0x76170000 ASLR <--  *** That's not my doing. Static linked ****
msctf.dll          C:\Windows\System32\msctf.dll 0x77BD0000 ASLR      
lpk.dll            C:\Windows\System32\lpk.dll 0x762E0000 ASLR
locale.nls         C:\Windows\System32\locale.nls 0x160000 n/a
KernelBase.dll     C:\Windows\System32\KernelBase.dll 0x75CD0000 ASLR
kernel32.dll       C:\Windows\System32\kernel32.dll 0x76720000 ASLR
imm32.dll          C:\Windows\System32\imm32.dll 0x75F80000 ASLR
imageres.dll       C:\Windows\System32\imageres.dll 0x2200000 n/a
gdi32.dll          C:\Windows\System32\gdi32.dll 0x77A30000 ASLR
dwmapi.dll         C:\Windows\System32\dwmapi.dll 0x73F60000 ASLR
cryptbase.dll      C:\Windows\System32\cryptbase.dll 0x75A10000 ASLR
apisetschema.dll   C:\Windows\System32\apisetschema.dll 0x77CC0000 ASLR
advapi32.dll       C:\Windows\System32\advapi32.dll 0x75FA0000 ASLR
SortDefault.nls    C:\Windows\Globalization\Sorting\SortDefault.nls 0x3880000 n/a
StaticCache.dat    C:\Windows\Fonts\StaticCache.dat 0x16D0000 n/a

- A

Admin wrote:Yes, there are certainly advantages to updating. It will obviously fix this particular problem. There are also many other fixes and improvements. Better performance and support for a few new formats, such as HEVC (the successor of H.264).

Well there's one bug fix that would decide it for me. And that is, (also with the built in mp3 decoder), if an mp3 contains an image in its ID3v2 tag, and you're working with large image files in clunky resource-hogs like Paint Shop Pro, then the playback gets stalled when a memory/processor-intensive image operation is in process. I don't know why, but it seems like mp3 images are loaded in the playback thread. I mean, I can see the reasons for doing so (only 1 file handle say) but if I'm not actually viewing the images (and I can't anyway with Media Player Classic I don't think) I don't want them loaded at all.

Actually I never want mp3 images loaded and I will probably just write an image stripping program instead of finding a better decoder.

- A

Why wouldn't you be able to test a release build? It will run normally. What we are talking about is only how a fatal exception is being handled. Nothing really special is being done. There is no debug stuff included.

What kind of CPU do you have? And how much RAM? It must be a pretty old machine if a mp3 isn't parsed quickly enough.

Yes, you wouldn't be able to test how a fatal exception is handled on the end-user's machine. That's really the only thing you would want to be sure of no? ... that the program exit cleanly without frightening messages popping up say. And that any unsaved data be flushed to disk, and an informational message about a program fault with a "restart program" option or something like that come up.

I mean, depending on how I'd want to handle fatal exceptions, I'd certainly need to be able to ensure that that code is working properly.

I only bought it about a year ago. Probably the same day I installed K-lite;). It's an ASUS laptop. It's fast enough.

If an mp3 has no image data then playback is never interrupted or stalled.

The normal action in case of such a fatal error is to terminate the whole process. Exactly what on of the buttons in your error dialog does.

If you want to handle the exception differently, you need to change your code, since with correct code there wouldn't be this kind of error. This has nothing to do with the MS documentation.

Yes, I realize that. But I wouldn't want some kind of MS dr. watson to show up for some internal reason ... like heap corruption say (internal to the rtl I mean).

I would, in a commercial product say, be handling that kind of critical error in such a way that I wouldn't be using the heap anymore, and instead relying on pre-allocated static buffers to do whatever I can to make a graceful exit.

Anyway, I understand your meaning. Thanks for all your help.