Avisynth+

[Reel.Deel]

Originally Posted by Groucho2004

Maybe you have a dodgy plugin. You should try with an empty auto-load directory.

So I kept getting the same error as in post #1932 with 32-bit r2003 and AVSMeter v2.2.9. I cleared out my auto-load directory. Added plugins until I got the error message again, it turns out the latest nnedi3 (v0.9.4.22). If I remove it, AVSMeter works as it should. Kinda odd that 64-bit nnedi3 works though.

Edit: removing nnedi3 from the auto-load folder also fixes the problem reported in post #1930.

[Groucho2004]

Originally Posted by Reel.Deel

So I kept getting the same error as in post #1932 with 32-bit r2003 and AVSMeter v2.2.9. I cleared out my auto-load directory. Added plugins until I got the error message again, it turns out the latest nnedi3 (v0.9.4.22). If I remove it, AVSMeter works as it should. Kinda odd that 64-bit nnedi3 works though.

Edit: removing nnedi3 from the auto-load folder also fixes the problem reported in post #1930.

Thanks for looking into this. I don't use that version of nnedi3 since I don't need the additional color spaces. I guess that's why I could not reproduce it.

[qyot27]

Well, it resolved itself here once I replaced the core plugins in plugins+ with the ones built with r2005.

[qyot27]

Thinking about this, can the Access Violation error message be made more verbose or checks made more robust so that errant plugins that cause issues like this get reported in the message and can be dealt with?

[LigH]

One may even think of a debug build using Windows Debug Messages readable with DebugView or DebugView++.

[MysteryX]

Originally Posted by qyot27

Thinking about this, can the Access Violation error message be made more verbose or checks made more robust so that errant plugins that cause issues like this get reported in the message and can be dealt with?

I don't even know how to locate such errors when debugging my own code. If there's a way, I'd love to hear about it.

[Groucho2004]

Originally Posted by qyot27

Thinking about this, can the Access Violation error message be made more verbose or checks made more robust so that errant plugins that cause issues like this get reported in the message and can be dealt with?

AVSMeter reports the module that caused the exception but that only works if Avisynth doesn't catch the exception first.
It should be simple to add this to the SEH code in Avisynth.

[ultim]

qyot, Reel, you two are kings! I checked the sources of nnedi3 after Reel found it was a possible cause, and realized what the problem is. The merge commit that qyot bisected reinforced my analysis. In short, nnedi3 needs to be recompiled at a minimum, and better, a small fix be made to it to avoid the problem in the future. EDIT: A proper fix needs to come from Avs+. See later posts.

Here is what happened:
1) In commit 2ee19354 of classic Avs (JEEB's repo), GetVarDef() was added to the IScriptEnv interface, and this was merged to Avs+ in the commit found by qyot.
2) The addition of GetVarDef is in general OK, because it maintains ABI for IScriptEnv, and while it breaks ABI for IScriptEnv2 (because it is a derived interface), it was merged anyway because IScriptEnv2 is not (yet) supposed to be used by external plugins. There is a big fat warning block above the interface definition that warns plugin developers, that the interface is not stable and should only be used for testing.
3) Now comes the fun part. nnedi3 ignored this warning, and in its newest version is relying on the unstable interface, which just got changed, and hence the plugin got broken.
4) War, famine, and epidemics, not to mention the wasted hours for the community in debugging this. Warnings are there for a reason. Once that warning gets remove, only then can you rely publicly on the interface.

This also explains why I couldn't reproduce this: I have an older version of nnedi3 that does not use IScriptEnv2.

It seems nnedi3 is using the unstable API to register its MT mode. The proper way to implement this functionality is instead of using IScriptEnv2, respond to the CACHE_GET_MTMODE query in the plugin's SetCacheHints() with the proper constant. Here is an example of doing it right. This is future proof and is compatible with both classic Avs and Avs+.
EDIT: Ah darn, this functionality got disabled in Avs+ to fix related problems. So a "proper fix" is not that easy. See comment below.

A real fix in Avs+ is not trivial, but a new build will still be issued later tonight to at least fix the HBD resizers and XP compatibility.

[Groucho2004]

Originally Posted by LigH

One may even think of a debug build using Windows Debug Messages readable with DebugView or DebugView++.

This won't tell you much if you don't write the code for catching structured exceptions.

[MysteryX]

Quite a few plugin authors, including me, started using IScriptEnv2 to set the MT mode.

Is there a way to use IScriptEnv2 so that it doesn't crash if the interface changes?

[Reel.Deel]

Originally Posted by ultim

qyot, Reel, you two are kings! I checked the sources of nnedi3 after Reel found it was a possible cause, and realized what the problem is. The merge commit that qyot bisected reinforced my analysis. In short, nnedi3 needs to be recompiled at a minimum, and better, a small fix be made to it to avoid the problem in the future.

Here is what happened:
1) In commit 2ee19354 of classic Avs (JEEB's repo), GetVarDef() was added to the IScriptEnv interface, and this was merged to Avs+ in the commit found by qyot.
2) The addition of GetVarDef is in general OK, because it maintains ABI for IScriptEnv, and while it breaks ABI for IScriptEnv2 (because it is a derived interface), it was merged anyway because IScriptEnv2 is not (yet) supposed to be used by external plugins. There is a big fat warning block above the interface definition that warns plugin developers, that the interface is not stable and should only be used for testing.
3) Now comes the fun part. nnedi3 ignored this warning, and in its newest version is relying on the unstable interface, which just got changed, and hence the plugin got broken.
4) War, famine, and epidemics, not to mention the wasted hours for the community in debugging this. Warnings are there for a reason. Once that warning gets remove, only then can you rely publicly on the interface.

This also explains why I couldn't reproduce this: I have an older version of nnedi3 that does not use IScriptEnv2.

It seems nnedi3 is using the unstable API to register its MT mode. The proper way to implement this functionality is instead of using IScriptEnv2, respond to the CACHE_GET_MTMODE query in the plugin's SetCacheHints() with the proper constant. Here is an example of doing it right. This is future proof and is compatible with both classic Avs and Avs+.

There's actually a few recent plugins using the same method as nnedi3. If I'm not mistaken a few from Chikuzen, and MysteryX's AviSynthShader.

It was asked about not too long ago: http://forum.doom9.org/showthread.ph...75#post1768175

See this also: http://forum.doom9.org/showthread.ph...38#post1768838

[ultim]

Originally Posted by Reel.Deel

There's actually a few recent plugins using the same method as nnedi3. If I'm not mistaken a few from Chikuzen, and MysteryX's AviSynthShader.

It was asked about not too long ago: http://forum.doom9.org/showthread.ph...75#post1768175

See this also: http://forum.doom9.org/showthread.ph...38#post1768838

Ah, okay, so nnedi3 actually had a proper reason for using IScriptEnv2. Either because of bug #37, or because I actually disabled the mechanism for CACHE_GET_MTMODE, also in a sad attempt to work around #37. Darn.

I see how this leaves plugins like nnedi3 in a crossfire... I'll try to come up with something for this problem.

[ultim]

Originally Posted by MysteryX

Is there a way to use IScriptEnv2 so that it doesn't crash if the interface changes?

Unfortunately, no there is not. Or else the warning wouldn't be there. Or at least not if the IScriptEnv is extended using inheritance, but any other method would be really ugly, also for plugin developers.

Basically what I need is a proper fix for #37 so that I can re-enable CACHE_GET_MTMODE.

[Reel.Deel]

Originally Posted by ultim

Ah, okay, so nnedi3 actually had a proper reason for using IScriptEnv2. Either because of bug #37, or because I actually disabled the mechanism for CACHE_GET_MTMODE, also in a sad attempt to work around #37. Darn.

I see how this leaves plugins like nnedi3 in a crossfire... I'll try to come up with something for this problem.

Correct, but nnedi3() works fine, it's nnedi3_rpow2() that's affected by bug #37. I think eedi3_rpow2() will have the same problem but I haven't checked.

[easyfab]

Hi,

I'm a simple user ( not a dev ) and I update to r2003 and it crashed for me with 32bit version, AvsPmod doesn't open for example. After research it comes with rawsource26.dll ( https://github.com/chikuzen/RawSource_2.6x/releases ). Remove this from plugins, it works again ? No problem with 64bit version.
Is this a problem with rawsource26 or avisynth+ ?

[Reel.Deel]

Originally Posted by easyfab

Hi,

I'm a simple user ( not a dev ) and I update to r2003 and it crashed for me with 32bit version, AvsPmod doesn't open for example. After research it comes with rawsource26.dll ( https://github.com/chikuzen/RawSource_2.6x/releases ). Remove this from plugins, it works again ? No problem with 64bit version.
Is this a problem with rawsource26 or avisynth+ ?

RawSource26 self-registers the MT mode the same way that latest nnedi3 does. See post #1955.

[easyfab]

Ok Thanks so it's a known problem.

[Reel.Deel]

Originally Posted by easyfab

Ok Thanks so it's a known problem.

Just recently

[qyot27]

It wasn't nnedi3 that caused it for me, I have an older version of it and hadn't updated. It was a mismatch between the plugins built with an early 16-bit test build from pinterf's branch, and the core of r2003/r2005, since I was using Windows' directory-first dll override tactic to make ffmpeg see the new build instead of the one in system32. Once I put the new plugins in the autoload directory, the problem went away.

So something changed in the plugins too. Probably DirectShowSource, since Reel.Deel mentioned that earlier.


And this wouldn't be the first time *VarDef has caused an issue. I couldn't figure out how to integrate it into avsplus properly back during RC1 when it was first brought into 2.6, so it may be piggybacking on that too.

[hector40]

Originally Posted by easyfab

Hi,

I'm a simple user ( not a dev ) and I update to r2003 and it crashed for me with 32bit version, AvsPmod doesn't open for example. After research it comes with rawsource26.dll ( https://github.com/chikuzen/RawSource_2.6x/releases ). Remove this from plugins, it works again ? No problem with 64bit version.
Is this a problem with rawsource26 or avisynth+ ?

I have the same problem with r2003 32bit, the plugins that crashing are, RawSource26-20160528, TCannyMod-1.2.0, yadifmod2-0.0.4.
The r2003 64bit, don't have the same problem.