May 11, 2021, 02:07:45 AM

News:

--


Crash on opening a certain file

Started by OnETime, November 21, 2020, 12:42:51 AM

Previous topic - Next topic

OnETime

When I try to open a certain file I have using Avidemux 2.7.6 on Mojave, it crashes with:

Assert failed :0
 file /Users/fx/hudson/workspace/MacOSX_Catalina/avidemux_plugins/ADM_demuxers/Mp4/ADM_atom.cpp, line 116

The same happens with 2.7.4, and the 2.7.7 version I compiled myself.

The file is a ".mov" QuickTime file in PAL DV format. I think it was output from Final Cut Pro many years ago. I don't think it's corrupted because it opens and plays fine in all other video apps I tried, including Handbrake, MPEG Streamclip, Compressor, VLC, Mpv, QuickTime Player, etc.

the terminal output has:

[HandleAction] 23:39:01-309  ************ OPEN_VIDEO **************
objc[15353]: Class FIFinderSyncExtensionHost is implemented in both /System/Library/PrivateFrameworks/FinderKit.framework/Versions/A/FinderKit (0x7fffa587b3d8) and /System/Library/PrivateFrameworks/FileProvider.framework/OverrideBundles/FinderSyncCollaborationFileProviderOverride.bundle/Contents/MacOS/FinderSyncCollaborationFileProviderOverride (0x119729f50). One of the two will be used. Which one is undefined.
[TS Demuxer] Probing...
 [checkMarker] 23:39:19-799  [Ts Demuxer] Sync ok :0 Sync ko :966
 [checkMarker] 23:39:19-800  [Ts Demuxer] Sync ok :0 Sync ko :966
 [detectTs] 23:39:19-800  [TS Demuxer] Not a TS file
 [TS Demuxer] Not a ts file
 [probe] 23:39:19-800   [picHeader] Cannot open that
Match wide
 [MP4]MP4/MOV/3GP file detected...
 [flvHeader] Cannot open that
 [openDML] Cannot open that
 [mxfHeader] Cannot open that (8000000)
 [probe] 23:39:19-801  [asfHeader] Cannot open that
 [avsProxy] Cannot open that
 [mkvHeader] Cannot open that
 match :0 / 455 (probeSize:1048576)
 [PS Demuxer] Not a ps file
** opening 3gpp files **
 [lookupMainAtoms] 23:39:19-812  Analyzing file and atoms
 [parseMvhd] 23:39:19-813  Warning: movie scale is 25
 [parseTrack] 23:39:19-813  Parsing Track
 [parseTrack] 23:39:19-813  EDTS atom found
 [parseEdts] 23:39:19-813  Parsing Edts, trackType=0
 [parseEdts] 23:39:19-813  ELST atom found
 [parseElst] 23:39:19-813  [ELST] Found 1 entries in list, version=0
 [parseElst] 23:39:19-813  Duration : 10870, mediaTime:0 speed=65536
 [parseElst] 23:39:19-813  delay = 0 in movie scale units, skip to time 0 in track scale units.
 [parseMdia] 23:39:19-813  <<Parsing Mdia>>
[HDLR]
 [parseMdia] 23:39:19-813  hdlr video found
  [parseStbl] 23:39:19-813  <<Parsing Stbl>>
 [parseStbl] 23:39:19-813  [STSD] VIDEO dvcp, size 86
[STSD] vendor appl
[STSD] width :720
[STSD] height :576
[STSD] datasize :0
[STSD] FrameCount :1
Codec string :8 <DV - PAL>
LEFT:0
Saving crash file to /Users/onetime/.avidemux6/crash.py
Crash Dump for Crash
Assert failed :0
 file /Users/fx/hudson/workspace/MacOSX_Catalina/avidemux_plugins/ADM_demuxers/Mp4/ADM_atom.cpp, line 116

eumagga0x2a

Could you please apply the patch below, rebuild Avidemux (if you didn't delete the results of the previous compilation, adding

--rebuild --without-core --without-qt --without-cli
to the bootstrap script command line will strongly speed up the process), install the freshly generated app bundle, load the file which triggered the crash, close Avidemux (when not crashed), then attach /tmp/admlog.txt to your reply.

Thanks.

The content of the patch for reference:

diff --git a/avidemux_plugins/ADM_demuxers/Mp4/ADM_atom.cpp b/avidemux_plugins/ADM_demuxers/Mp4/ADM_atom.cpp
index 2b702f17d..3a1bf5fb5 100644
--- a/avidemux_plugins/ADM_demuxers/Mp4/ADM_atom.cpp
+++ b/avidemux_plugins/ADM_demuxers/Mp4/ADM_atom.cpp
@@ -110,10 +110,22 @@ int64_t pos;
 #ifdef ATOM_DEBUG
         printf("Atom: Skipping %d bytes\n",nb);
 #endif
-
+ pos=ftello(_fd);
+ if(pos+nb>_atomStart+_atomSize+1)
+ {
+ ADM_warning("Trying to seek past the end of atom %s by %" PRId64" bytes to position 0x%" PRIx64"\n",
+ fourCC::tostringBE(_atomFCC), pos-_atomStart-_atomSize-1, pos+nb);
+ skipAtom();
+ return 1;
+ }
  fseeko(_fd,nb,SEEK_CUR);
  pos=ftello(_fd);
- if(pos>_atomStart+_atomSize+1) ADM_assert(0);
+ if(pos>_atomStart+_atomSize+1)
+ {
+ ADM_error("Fatal: seeking beyond the end of atom %s by %" PRId64" bytes, position: 0x%" PRIx64"\n",
+ fourCC::tostringBE(_atomFCC), pos-_atomStart-_atomSize-1, pos);
+ ADM_assert(0);
+ }
  return 1;
 }
 

eumagga0x2a

If the content of the file allows the file to be provided as a sample, it would simplify pretty much everything if I could inspect the file myself.

The assert failure indicates that either an atom (my patch tries to identify which one) is corrupted and the atom size, stored in the first 4 bytes, is bogus, or there is a bug in the demuxer so that Avidemux tries to read past the end of the atom.

OnETime2

Sorry about the delay, I had to use another tool to get the job done...

I just built 2.7.8 for Mojave, so I tested it with that file and it still crashes. I applied the patch. After that, it doesn't crash, and the file opens and plays. I've attached the log. Maybe I could send you the file if necessary, but it's almost 2 GB.

eumagga0x2a

Thank you very much for the log, it is now roughly clear at which spot the problem happens. It would be still indispensable to get the file as sample to determine with confidence whether the file is broken or we are doing something wrong and what are the options.

Up to 2 GiB is totally fine as this is within WeTransfer limits (I had to deal with samples ~ 10 GiB in size already, provided via Google Drive). The only condition is that the content is innocuous enough / not sensitive.

OnETime2

Ok, I'll upload it and pm you the link. It's possible it's a bit broken, but as I said, every other application I tried had no problem playing it.

eumagga0x2a

Thank you very much for the sample, what a pity that you waited until shortly after the release.

For some inexplicable reason, your sample has two sample description (stsd) entries for video which are almost identical with the only difference being a higher revision level in the second one (the old Apple QuickTime file format documentation states that this field must be zero, therefore the second entry may be invalid anyway). The vast majority of MP4 and MOV files "in the wild" has just a single one stsd entry for video.

Avidemux evaluates only the first video sample description and should skip all others, but the code was missing a command to seek exactly to the start of the next entry. This resulted in Avidemux reading the size of the next entry from a wrong offset. If the wrong size by chance exceeded the size of the stsd atom like with your sample, we crashed.

Should be fixed by [demuxers/Mp4] Fix crash with multiple stsd entries for video.

Thank you for your report.

OnETime2

Thanks... I replaced that file and rebuilt it, and it loads without crashing now.

Again sorry about the delay, I had to move on and use something else at the time, and I deleted the build directory etc. I just had some time now to come back to it. I didn't know about the release.

Btw, couldn't you just build the release with a 10.14 target so it would run on Mojave and later? I think a lot of people like me are still on Mojave for the 32-bit support. Does Avidemux use anything exclusive to Catalina? I'm just asking, I don't really know that much about it...

eumagga0x2a

Quote from: OnETime2 on March 25, 2021, 08:09:38 PMcouldn't you just build the release with a 10.14 target so it would run on Mojave and later?

While Avidemux itself, internal libraries and bundled FFmpeg can be built on Catalina with Mojave as target, all the stuff from Homebrew cannot be used, which leaves Avidemux half-broken. This was the reason this solution has been abandoned.