Issue with wine and ALL versions of 2.6 (Resolved)

[tcope]

There appears to be an issue with wine,
and all versions of 2.6 .

All tests are done in single thread mode. All AVS versions
with multi-thread support, crash horribly when it is enabled.

The issue becomes apparent when running deshaker.
I am guessing it has to do with how processes
are spawned.

To quell those who will jump to blame the avs script,
it is a very basic script, with all default settings.
source="NEW-TEST.mkv"
LoadVirtualDubPlugin ("C:\Program Files\AviSynth-repo\plugins32\deshaker.vdf", "deshaker", preroll=0)
FFVideoSource(source)

clip=ConvertToRGB32()

clip.deshaker("
19|1|30|4|1|0|1|0|1920|1080|
1|2|1000|1000|1000|1000|4|1|0|2|
8|30|300|4|C:\Deshaker.log|0|0|0|0|0|
0|0|0|0|0|0|1|1|1|15|
15|5|15|0|0|30|30|0|0|1|
0|1|0|0|10|1000|1|104|1|1|
20|5000|100|20|1|0|ff00ff")

clip.deshaker("
19|2|30|4|1|0|1|0|1920|1080|
1|2|1000|1000|1000|1000|4|1|0|2|
8|30|300|4|C:\Deshaker.log|0|0|0|0|0|
0|0|0|0|0|0|1|1|1|15|
15|5|15|0|0|30|30|0|0|1|
0|1|0|0|10|1000|1|104|1|1|
20|5000|100|20|1|0|ff00ff")


Deshaker requires 2 passes and writes the log file
on pass 1 for pass 2 to use. If the log file is not
found, the video output is black.

Not sure if winxp is even supported with avisynth any more,
but wine set to xp helps demonstrates what is happening.
The log file never gets written, and the output is black.
Even writing functions and trying a few tricks to create
a more sequential flow, still produces the same results.
Running a script with pass 1 then running another script
with pass 2, produces the correct clip.

Running wine set to win7 provides more stability. However,
the issue behaves differently. When running both passes
in the same script, The clip output is correct for the first
few seconds then turns black. My guess is because pass 1 has
to calculate all the motion vectors, it takes longer than
pass 2, and pass 2 just outruns pass 1

Though much worse with xp, the behavior seems to indicate
improper or incompatible internal process syncing.

Synth+ will sometimes get most way done but tends to crash
so hard the terminal becomes unusable and needs be closed.

Perhaps this backtrace from AVS+ r2455 will shine some light on the issue.
Unhandled exception: page fault on read access to 0x076860f0 in 32-bit code (0x076860f0).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:076860f0 ESP:032bfa54 EBP:032bfa78 EFLAGS:00210206( R- -- I - -P- )
EAX:036b446c EBX:036bfcd4 ECX:076860f0 EDX:036b4374
ESI:036b4370 EDI:036bfc7c
Stack dump:
0x032bfa54: 074318d9 036b446c 07437000 036b4370
0x032bfa64: 036b4370 f6fa42a5 032bfa90 0743439c
0x032bfa74: 00000003 032bfa9c 07431a78 036b4370
0x032bfa84: 1006455a 00000001 036bfcd0 032bfac4
0x032bfa94: 101114d0 ffffffff 032bfad0 10068839
0x032bfaa4: 035fe264 036b4348 036bfc70 10067deb
000c: sel=0067 base=00000000 limit=00000000 32-bit --x
Backtrace:
=>0 0x076860f0 (0x032bfa78)
1 0x07431a78 in vdubfilter (+0x1a77) (0x032bfa9c)
2 0x10068839 in avisynth (+0x68838) (0x032bfad0)
3 0x10067e18 in avisynth (+0x67e17) (0x032bfaf4)
4 0x100601db in avisynth (+0x601da) (0x032bfb14)
5 0x1006039a in avisynth (+0x60399) (0x032bfb34)
6 0x10064511 in avisynth (+0x64510) (0x032bfb50)
7 0x10050a64 in avisynth (+0x50a63) (0x032bfb94)
8 0x10051938 in avisynth (+0x51937) (0x032bfbc8)
9 0x01e652d0 in ffmpeg (+0x1a652cf) (0x00246880)
0x076860f0: addb %al,0x0(%eax)
Modules:
Module Address Debug info Name (193 modules)
PE 350000- 365000 Deferred addgrainc
PE 370000- 37a000 Deferred convertstacked
PE 380000- 3f9000 Deferred depan
PE 400000- 30ba000 Export ffmpeg
PE 4010000- 4075000 Deferred depanestimate
PE 4080000- 40ad000 Deferred dfttest
PE 41c0000- 41d6000 Deferred directshowsource
PE 41e0000- 41f7000 Deferred eedi2
PE 4310000- 432f000 Deferred eedi3
PE 4440000- 5683000 Deferred ffms2
PE 5690000- 56c8000 Deferred fft3dfilter
PE 57e0000- 57f1000 Deferred imageseq
PE 5800000- 5abe000 Deferred devil
PE 5bd0000- 5ca7000 Deferred masktools2
PE 5cb0000- 5dd5000 Deferred mvtools2
PE 5de0000- 5e37000 Deferred nnedi
PE 5f50000- 5f93000 Deferred nnedi2
PE 60b0000- 6ddd000 Deferred nnedi3
PE 6ef0000- 6f04000 Deferred repairsse2
PE 7020000- 7050000 Deferred resamplehq-x86
PE 7160000- 718b000 Deferred rgtools
PE 7190000- 71a8000 Deferred shibatch
PE 71b0000- 71bb000 Deferred sse2tools
PE 72d0000- 730f000 Deferred tdeint
PE 7420000- 742d000 Deferred timestretch
PE 7430000- 743b000 Export vdubfilter
PE 7440000- 744f000 Deferred verticalcleanersse2
PE 7560000- 756d000 Deferred yadif
PE 10000000-1019b000 Export avisynth
ELF 7b400000-7b7ed000 Deferred kernel32<elf>
\-PE 7b420000-7b7ed000 \ kernel32
ELF 7bc00000-7bd02000 Deferred ntdll<elf>
\-PE 7bc10000-7bd02000 \ ntdll
ELF 7c000000-7c004000 Deferred <wine-loader>
ELF 7defd000-7df2d000 Deferred p11-kit-trust.so
ELF 7df2d000-7df34000 Deferred libffi.so.6
ELF 7df34000-7df70000 Deferred libp11-kit.so.0
ELF 7df70000-7df84000 Deferred libtasn1.so.6
ELF 7df84000-7df9e000 Deferred libz.so.1
ELF 7df9e000-7e025000 Deferred libgcrypt.so.11
ELF 7e025000-7e0eb000 Deferred libgnutls.so.26
ELF 7e0eb000-7e10d000 Deferred libtinfo.so.5
ELF 7e10d000-7e132000 Deferred libncurses.so.5
ELF 7e15b000-7e216000 Deferred winmm<elf>
\-PE 7e160000-7e216000 \ winmm
ELF 7e216000-7e292000 Deferred shlwapi<elf>
\-PE 7e220000-7e292000 \ shlwapi
ELF 7e292000-7e564000 Deferred shell32<elf>
\-PE 7e2a0000-7e564000 \ shell32
ELF 7e564000-7e5a2000 Deferred ws2_32<elf>
\-PE 7e570000-7e5a2000 \ ws2_32
ELF 7e5a2000-7e5cd000 Deferred iphlpapi<elf>
\-PE 7e5b0000-7e5cd000 \ iphlpapi
ELF 7e5cd000-7e5fe000 Deferred netapi32<elf>
\-PE 7e5d0000-7e5fe000 \ netapi32
ELF 7e5fe000-7e633000 Deferred secur32<elf>
\-PE 7e600000-7e633000 \ secur32
ELF 7e633000-7e77a000 Deferred oleaut32<elf>
\-PE 7e650000-7e77a000 \ oleaut32
ELF 7e77a000-7e800000 Deferred rpcrt4<elf>
\-PE 7e790000-7e800000 \ rpcrt4
ELF 7e800000-7e949000 Deferred ole32<elf>
\-PE 7e820000-7e949000 \ ole32
ELF 7e949000-7ea07000 Deferred msvcrt<elf>
\-PE 7e960000-7ea07000 \ msvcrt
ELF 7ea07000-7ea21000 Deferred version<elf>
\-PE 7ea10000-7ea21000 \ version
ELF 7ea21000-7eb87000 Deferred user32<elf>
\-PE 7ea30000-7eb87000 \ user32
ELF 7eb87000-7ebad000 Deferred imm32<elf>
\-PE 7eb90000-7ebad000 \ imm32
ELF 7ebad000-7ece4000 Deferred gdi32<elf>
\-PE 7ebc0000-7ece4000 \ gdi32
ELF 7ece4000-7ed60000 Deferred advapi32<elf>
\-PE 7ecf0000-7ed60000 \ advapi32
ELF 7ef60000-7ef6c000 Deferred libnss_files.so.2
ELF 7ef6c000-7ef78000 Deferred libnss_nis.so.2
ELF 7ef78000-7ef91000 Deferred libnsl.so.1
ELF 7ef91000-7efd7000 Deferred libm.so.6
ELF 7efd7000-7efeb000 Deferred psapi<elf>
\-PE 7efe0000-7efeb000 \ psapi
ELF 7efeb000-7f000000 Deferred avicap32<elf>
\-PE 7eff0000-7f000000 \ avicap32
ELF f5ce7000-f5d04000 Deferred libgcc_s.so.1
PE f5d48000-f5d5d000 Deferred api-ms-win-appmodel-runtime-l1-1
PE f5d50000-f5d5d000 Deferred api-ms-win-appmodel-runtime-l1-1C:\windows\system32\api-ms-win-appmodel-runtime-l1-1-1.dll
ELF f5d5d000-f5d71000 Deferred api-ms-win-core-file-l2-1-1<elf>
\-PE f5d60000-f5d71000 \ api-ms-win-core-file-l2-1-1
ELF f5db5000-f5dbe000 Deferred librt.so.1
ELF f5dbe000-f5dd6000 Deferred libresolv.so.2
ELF f5dd6000-f5dda000 Deferred libkeyutils.so.1
ELF f5dda000-f5e25000 Deferred libdbus-1.so.3
ELF f5e25000-f5e31000 Deferred libkrb5support.so.0
ELF f5e31000-f5e61000 Deferred libk5crypto.so.3
ELF f5e61000-f5f20000 Deferred libkrb5.so.3
ELF f5f20000-f5f32000 Deferred libavahi-client.so.3
ELF f5f32000-f5f40000 Deferred libavahi-common.so.3
ELF f5f40000-f5f86000 Deferred libgssapi_krb5.so.2
ELF f5f86000-f5ff3000 Deferred libcups.so.2
ELF f6257000-f630e000 Deferred msvcr71<elf>
\-PE f6270000-f630e000 \ msvcr71
ELF f630e000-f63d5000 Deferred msvcr80<elf>
\-PE f6330000-f63d5000 \ msvcr80
ELF f63d5000-f6533000 Deferred msvcp80<elf>
\-PE f6410000-f6533000 \ msvcp80
ELF f6533000-f6551000 Deferred vcomp<elf>
\-PE f6540000-f6551000 \ vcomp
ELF f6551000-f6567000 Deferred vcomp100<elf>
\-PE f6560000-f6567000 \ vcomp100
ELF f6567000-f65b7000 Deferred dsound<elf>
\-PE f6570000-f65b7000 \ dsound
ELF f65b7000-f66b6000 Deferred quartz<elf>
\-PE f65d0000-f66b6000 \ quartz
PE f66b6000-f66ca000 Deferred api-ms-win-core-localization-l1-
PE f66c0000-f66ca000 Deferred api-ms-win-core-localization-l1-C:\windows\system32\api-ms-win-core-localization-l1-2-1.dll
ELF f66ca000-f66de000 Deferred api-ms-win-core-fibers-l1-1-1<el
PE f66d0000-f66de000 Deferred api-ms-win-core-fibers-l1-1-1
ELF f66de000-f66f2000 Deferred api-ms-win-core-synch-l1-2-0<elf
PE f66e0000-f66f2000 Deferred api-ms-win-core-synch-l1-2-0
ELF f6738000-f6772000 Deferred uxtheme<elf>
\-PE f6740000-f6772000 \ uxtheme
ELF f6772000-f6778000 Deferred libxfixes.so.3
ELF f6778000-f6783000 Deferred libxcursor.so.1
ELF f6785000-f678a000 Deferred libcom_err.so.2
ELF f678a000-f67aa000 Deferred concrt140<elf>
\-PE f6790000-f67aa000 \ concrt140
ELF f681e000-f6847000 Deferred libexpat.so.1
ELF f6847000-f6882000 Deferred libfontconfig.so.1
ELF f6882000-f68aa000 Deferred libpng12.so.0
ELF f68aa000-f694a000 Deferred libfreetype.so.6
ELF f694a000-f695a000 Deferred libxi.so.6
ELF f695a000-f695e000 Deferred libxcomposite.so.1
ELF f695e000-f6969000 Deferred libxrandr.so.2
ELF f6969000-f6974000 Deferred libxrender.so.1
ELF f6974000-f697a000 Deferred libxxf86vm.so.1
ELF f697a000-f697e000 Deferred libxinerama.so.1
ELF f697e000-f69a0000 Deferred libxcb.so.1
ELF f69a0000-f6ad4000 Deferred libx11.so.6
ELF f6ad4000-f6ae7000 Deferred libxext.so.6
ELF f6b10000-f6ba3000 Deferred winex11<elf>
\-PE f6b20000-f6ba3000 \ winex11
ELF f6ba3000-f6bb7000 Deferred api-ms-win-crt-time-l1-1-0<elf>
\-PE f6bb0000-f6bb7000 \ api-ms-win-crt-time-l1-1-0
ELF f6bb7000-f6bcd000 Deferred api-ms-win-crt-convert-l1-1-0<el
PE f6bc0000-f6bcd000 Deferred api-ms-win-crt-convert-l1-1-0
ELF f6bcd000-f6be1000 Deferred api-ms-win-crt-utility-l1-1-0<el
PE f6bd0000-f6be1000 Deferred api-ms-win-crt-utility-l1-1-0
ELF f6be1000-f6bf5000 Deferred api-ms-win-crt-locale-l1-1-0<elf
PE f6bf0000-f6bf5000 Deferred api-ms-win-crt-locale-l1-1-0
PE f6bf5000-f6c09000 Deferred api-ms-win-crt-filesystem-l1-1-0
PE f6c00000-f6c09000 Deferred api-ms-win-crt-filesystem-l1-1-0C:\windows\system32\api-ms-win-crt-filesystem-l1-1-0.dll
PE f6c09000-f6c1d000 Deferred api-ms-win-crt-environment-l1-1-
PE f6c10000-f6c1d000 Deferred api-ms-win-crt-environment-l1-1-C:\windows\system32\api-ms-win-crt-environment-l1-1-0.dll
ELF f6c1d000-f6c33000 Deferred api-ms-win-crt-string-l1-1-0<elf
PE f6c20000-f6c33000 Deferred api-ms-win-crt-string-l1-1-0
ELF f6c33000-f6c4c000 Deferred api-ms-win-crt-math-l1-1-0<elf>
\-PE f6c40000-f6c4c000 \ api-ms-win-crt-math-l1-1-0
ELF f6c4c000-f6c62000 Deferred api-ms-win-crt-stdio-l1-1-0<elf>
\-PE f6c50000-f6c62000 \ api-ms-win-crt-stdio-l1-1-0
ELF f6c62000-f6c76000 Deferred api-ms-win-crt-heap-l1-1-0<elf>
\-PE f6c70000-f6c76000 \ api-ms-win-crt-heap-l1-1-0
ELF f6c76000-f6c8c000 Deferred api-ms-win-crt-runtime-l1-1-0<el
PE f6c80000-f6c8c000 Deferred api-ms-win-crt-runtime-l1-1-0
ELF f6c8c000-f6d65000 Deferred msvcr110<elf>
\-PE f6ca0000-f6d65000 \ msvcr110
ELF f6d65000-f6e88000 Deferred msvcp110<elf>
\-PE f6da0000-f6e88000 \ msvcp110
ELF f6e88000-f6f67000 Deferred msvcr120<elf>
\-PE f6ea0000-f6f67000 \ msvcr120
ELF f6f67000-f7058000 Deferred ucrtbase<elf>
\-PE f6f80000-f7058000 \ ucrtbase
ELF f7058000-f7179000 Deferred msvcp140<elf>
\-PE f7090000-f7179000 \ msvcp140
ELF f7179000-f7286000 Deferred comctl32<elf>
\-PE f7180000-f7286000 \ comctl32
ELF f7286000-f72b3000 Deferred msvfw32<elf>
\-PE f7290000-f72b3000 \ msvfw32
ELF f72b3000-f72df000 Deferred msacm32<elf>
\-PE f72c0000-f72df000 \ msacm32
ELF f72df000-f7330000 Deferred avifil32<elf>
\-PE f72f0000-f7330000 \ avifil32
ELF f7330000-f7339000 Deferred libnss_compat.so.2
ELF f733a000-f733f000 Deferred libdl.so.2
ELF f733f000-f74ee000 Deferred libc.so.6
ELF f74ef000-f750b000 Deferred libpthread.so.0
ELF f750b000-f7510000 Deferred libgpg-error.so.0
ELF f7512000-f7519000 Deferred libxdmcp.so.6
ELF f7519000-f751d000 Deferred libxau.so.6
ELF f751d000-f7533000 Deferred vcruntime140<elf>
\-PE f7520000-f7533000 \ vcruntime140
ELF f7534000-f7703000 Dwarf libwine.so.1
ELF f7705000-f7727000 Deferred ld-linux.so.2
ELF f7727000-f7728000 Deferred [vdso].so
Threads:
process tid prio (all id:s are in hex)
00000008 (D) c:\FFMPEG\bin\ffmpeg.exe
[c:\FFMPEG\bin\ffmpeg.exe -i c:\TESTIT\TEST.avs output.mkv]
0000003f 0
0000003e 0
0000003d 0
0000003c 0
00000009 0 <==
0000000e services.exe
00000033 0
00000032 0
00000027 0
00000021 0
00000016 0
00000012 0
0000000f 0
00000010 explorer.exe
00000031 0
00000030 0
0000002f 0
0000002e 0
00000011 0
00000014 winedevice.exe
00000020 0
0000001b 0
0000001a 0
00000015 0
0000001e plugplay.exe
00000024 0
00000023 0
0000001f 0
00000025 winedevice.exe
00000037 0
00000036 0
00000035 0
00000034 0
0000002d 0
0000002a 0
00000029 0
00000026 0
000000e4 explorer.exe
000000e9 0
000000e8 0
000000e7 0
000000e6 0
000000e5 0
System information:
Wine build: wine-2.3 (Staging)
Platform: i386 (WOW64)
Version: Windows 7
Host system: Linux
Host version: 3.13.0-24-generic


Running AVSMeter on the avs script shows no issues
except for AVS+ which shows
Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
for which ever various plugin is relevant at the time.

On AVS+ , even taking deshaker out of the equation and
only running the clip through the latest QTGMC.
AVSMeter shows this
wine AVSMeter.exe -i 'c:\TESTIT\NEW-TEST.avs'
.
.
.
System exception - Access Violation
(C:/Program Files/AviSynth-repo/plugins32/QTGMC.avsi, line 981)
(C:/Program Files/AviSynth-repo/plugins32/QTGMC.avsi, line 724)


Tell me what you need and how I can help ?

[tcope]

I have not been able to reproduce this error,
but hopefully it will mean something.

Have no idea of its relevance and have
only seen it happen once on AVS260_MT.
err:clipboard:convert_selection Timed out waiting for SelectionNotify eventbits/s speed=0.0153x
err:clipboard:convert_selection Timed out waiting for SelectionNotify eventbits/s speed=0.0154x

[pinterf]

In avs+ there seems to be a double free of vd filter descriptors (a chain is built, and by the time the Clip is destroyed at the exit, next and previous ones are undefined, and as such, deleting them crashes), but it occurs only at the exit. I remember that this part was modified already due to finalization problems. In avs and then on avs+ as well.

[tcope]

With regards to QTGMC and AVS+

I have tried 5 different versions,
starting from 3.32 through 3.354.

Every version fails to run with error
System exception - Access Violation

[Groucho2004]

With regards to QTGMC and AVS+

I have tried 5 different versions,
starting from 3.32 through 3.354.

Every version fails to run with error
System exception - Access Violation
Please post an AVSMeter info log (-avsinfo -log).

[tcope]

Download avsinfo log here.
avsinfo.log (http://criteriondigital.net/AviSynth/avsinfo.log)

[Groucho2004]

Download avsinfo log here.
avsinfo.log (http://criteriondigital.net/AviSynth/avsinfo.log)
Looks OK. Just for testing, remove yadif (use Yadifmod2 (https://forum.doom9.org/showthread.php?t=173316&highlight=yadifmod) instead) and SSETools. Also, you should remove RepairSSE2 and VerticalCleanerSSE2 permanently since these are covered by RGTools.

[tcope]

Looks OK. Just for testing, remove yadif (use Yadifmod2 (https://forum.doom9.org/showthread.php?t=173316&highlight=yadifmod) instead) and SSETools. Also, you should remove RepairSSE2 and VerticalCleanerSSE2 permanently since these are covered by RGTools.
You Rock..!!

That seems to have solved the issue with QTGMC.
I had previously tried back and forth with
the yadifmod2 with no obvious effect. However,
removing the SSE2Tools, RepairSSE2,
and VerticalCleanerSSE2 looks to have solved the
stability issue with QTGMC.

The other issues still remain, so I will dig into all the
plugins I have installed and try to find the latest versions
of them all.

Here is the current avsinfo log
avsinfo.log (http://criteriondigital.net/AviSynth/avsinfo.log)

Thank You Sir :)

[tcope]

To recap, all the previous testing
had run successfully in win7. The issues
that are being experienced are wine
compatability issues, and removing
outdated plugins has improved stability.

Updated some plugins, and QTGMC
continues to work correctly. My focus
is now onto Deshaker.

While looking for various "newer"
plugins, I found the most stability
with 2.6 plugins.

Was very odd to find newer versions
of some, but they still used the 2.5
interface. Even though they were "newer",
things crashed.

So I basically updated to the latest versions
of the ones I could, while staying with 2.6
interface.
Here is the current avsinfo log.
avsinfo.log (http://criteriondigital.net/AviSynth/avsinfo.log)

At this point all AVS versions seem to behave
similarly in single thread mode.
When pass1 and pass2 are in separate scripts,
the pass1 logs are created and clips are processed
with proper outputs as expected. All AVS versions
will run to completion with no errors.

When both passes are set in one script, pass 1
does not seem to be processed. Though the frame
rate would indicate that it is. However, no log file
is generated, and the resulting clip is black.
All versions do run through to completion. However,
AVS+ crashes on exit. This may be what is described here.
In avs+ there seems to be a double free of vd filter descriptors (a chain is built, and by the time the Clip is destroyed at the exit, next and previous ones are undefined, and as such, deleting them crashes), but it occurs only at the exit.

wine: Unhandled page fault on read access to 0x06fe60f0 at address 0x6fe60f0 (thread 0009), starting debugger...
The backtrace can be found here.
backtrace.txt (http://criteriondigital.net/AviSynth/backtrace.txt)

AVS+ seems to run in single thread mode about 50%
faster than I am getting with AVS260_MT threaded.

Multi-thread modes:
AVS260_MT does run about 24% faster when threaded,
and completes with no errors
( Other than same pass1 issue & black output )

AVS+ imediately crashes if both passes are in the same
script. Even when passes are in separate scripts, it crawls
at a snale's pace. Nearly half the speed as in single thread
mode.
wine: Call from 0x7b43f1c2 to unimplemented function msvcp140.dll.?__ExceptionPtrAssign@@YAXPAXPBX@Z, aborting
wine: Call from 0x7b43f1c2 to unimplemented function msvcp140.dll.?__ExceptionPtrAssign@@YAXPAXPBX@Z, aborting
wine: Call from 0x7b43f1c2 to unimplemented function msvcp140.dll.?__ExceptionPtrAssign@@YAXPAXPBX@Z, aborting
wine: Call from 0x7b43f1c2 to unimplemented function msvcp140.dll.?__ExceptionPtrAssign@@YAXPAXPBX@Z, aborting
wine: Call from 0x7b43f1c2 to unimplemented function msvcp140.dll.?__ExceptionPtrAssign@@YAXPAXPBX@Z, aborting
wine: Call from 0x7b43f1c2 to unimplemented function msvcp140.dll.?__ExceptionPtrAssign@@YAXPAXPBX@Z, aborting
wine: Call from 0x7b43f1c2 to unimplemented function msvcp140.dll.?__ExceptionPtrAssign@@YAXPAXPBX@Z, aborting
wine: Call from 0x7b43f1c2 to unimplemented function msvcp140.dll.?__ExceptionPtrAssign@@YAXPAXPBX@Z, aborting
wine: Unhandled page fault on write access to 0x847ce330 at address 0x6ff2e2a (thread 0009), starting debugger...

The backtrace can be found here.
MT-backtrace.txt (http://criteriondigital.net/AviSynth/MT-backtrace.txt)

Please let me know if there is anything else I can
provide to help get this fixed.
Cheers :)

[LigH]

Just replied in the AviSynth+ thread...

Your script structure is wrong. Apparently you try to run a sequence of two DeShaker calls, which won't happen due to the assignment of different results to the same implicit last clip variable, which AviSynth detects and will not execute the first call at all.

...
clip = ConvertToRGB32()
last = clip.deshaker({ParamSet1}) # ignored due to the following call superseding the output
last = clip.deshaker({ParamSet2}) # this is the call producing the script output

Furthermore, you can't run two passes in one script because AviSynth will run the sequence per frame, not per clip. Means: AviSynth would (if you manage to execute both DeShaker calls in a sequence) process the first frame in the first-pass call, starting to create a log file, then process the first frame in the second-pass call, which can not yet read the log file because the first pass did not finish it yet ...

No, you really have to use two scripts, you have to run the first script with a first-pass call only, close it, and then open the second script with the second-pass call.

[tcope]

Apparently 80 hour work weeks, and the frustration
of trying to get this all working across a 20
node Linux cluster has taken its toll on me.

I had done testing of this years ago with version 2.5.
However, all I have been able to find was an avs
file of sorts. Now it would seem they were notes,
rather than functioning code.

Combine that with some how messing up my testing
on windows7, being used as a control for results.
Not sure how, but appeared to work correctly yesterday.

Following your input, I went and ripped out everything
from win7 and started fresh there. Sure enough it is
demonstrating the same type behavior as I am seeing
in wine.

I was unclear on how the frame chain was processed.
I was making an assumption that the 2 calls were able
to sync through that file. One would write and the
other would read. Such things are done at times, but
apparently not with Synth code.

As it stands, the only compatibility there seems to
have been was with wine and mix matched 2.5/2.6 plugins.
I may have even managed to get stability with AVS+ in
multi-thread mode.

Perhaps some creative scripting with GScript will allow
for both passes to be managed in one avs file. Would
deff make life easier running through the render farm.

Thanks LigH for helping me get my head screwed on straight.
I'll mark this thread as resolved.
Cheers :)

[LigH]

Sounds not very healthy, this stress level :scared: ... Be well, relax when possible. :)