Assert failed :3==sscanf(...) at line 140, file /.../ADM_tsReadIndex.cpp

[mm0359]

Virtual PC 2004 SP1
+
Windows XP
+
avidemux_2.6.18_r170313_win32.exe (r723b9080f91) ((ffmpeg 3.0.7))

I've got 1 .ts file (2.55 GB), accessed through Shared Folders,
Indexing seems to go well up to 98%,
then reading the created index file crashes:

...
[ADM_tsAccess] 22:48:12-676 Creating audio track, pid=84, muxing =0
[TsDemuxerer] Reading index
Saving crash file to Z:\...\crash.py
Crash Dump for Assert failed :3==sscanf(cur,"%" PRIx32":%" PRId64":%" PRId64,&len,&ppts,&ddts) at line 140, file /home/fx/hudson/workspace/mingw32QT5Mxe/avidemux_plugins/ADM_demuxers/MpegTS/ADM_tsReadIndex.cpp

ADM_setCrashHook  [libADM_core6.dll]
ADM_backTrack  [libADM_core6.dll]

Paint event
[abortExitHandler] 22:50:43-184 Abnormal exit handler, trying to clean up

See CDafv-170319.ts.idx2.7z (400 KB).

1) Is it indexing or reading code that is actually wrong?
   Indexing does create a bad .ts.idx2! Then reading it crashes...
2) If need be, I could upload (part of) the .ts file, but I would need to know which one is interested.
   The file content is not the trigger, it is the file size: ">= 2 GiB".

NB:
*First time I ever get this crash.
Because I was not using a/this virtual environment before!
*"Regression": ADM 2.6.8 works fine with this .ts file.
Actually, no: v2.6.8 has the same issue when run on VPC+WXP+SF.

PS:
*I have not tried (yet) VPC+WXP without indexing through SF.

[mean]

A stupidly long gop is processed at the end
Workaround : delete the very last long line just before [End]
Without the ts file i can't check why

[mm0359]

A stupidly long gop is processed at the end
Workaround : delete the very last long line just before [End]
Without the ts file i can't check why

I updated my initial comment:
I reproduced this issue with 2 other files, and found the trigger:
something is going wrong when reaching file offset ">= 2 GiB".

Example .ts.idx2 ends with:

Code Select Expand


...
Audio bf:7ff61734 ...
Video at:7ff3c690:0019 ...
Audio bf:7fff69ec ...
Video at:7ffd6140:0019 ... (<- overly long line)
[End]

I assume next offset would be ">= 0x80000000".

Ftb, I would assume the size limitation is (somehow) caused by my virtual environment.
Yet, it would look like ADM is not handling it correctly.

[mm0359]

[ts/demux] Make it more robust
worked around the reading crash.

This is nicer, though it silently "truncates" the file (size) to its first 2 GiB.
(2h27mn52s in my case.)

Thus, it seems wanted to check(/improve) index writing code (too)...

[mean]

Are you reading the file over samba ?

[mm0359]

Are you reading the file over samba ?

Not explicitly. (But could be under the hood?)

"Shared Folders" is a Guest Additions feature of VPC:
as a user, it maps a host drive/path to a guest drive;
internally, it works like/using "network", but there is no further details.

[mm0359]

Ah, "reproduced" with EditPad Pro 7.6.0:
file can be open and navigated normally,
but all data are 0x00 starting at 0x80000000.

EPP does not report any failure either :-|
(Scary (environment)!)

[mm0359]

Some more VPC+WXP+SF tests:
copy starts then errors out at 2 GiB.

Code Select Expand


*copy:
"The request could not be performed because of an I/O device error."
*Xcopy:
"Access denied"
*Explorer (Copy+Paste):
"The request could not be performed because of an I/O device error."


This fully confirms trigger is at OS/VM level.

Yet, it would look like the error can be detected and reported. (Hopefully by non-OS software too.)
Maybe ADM (video file reading) can be improved with this regard?