S
Steffen Lötzsch
Guest
Hi,
there seems to be a bug in vbscript.dll since cumulative update KB4524570 for Windows 10 1903. When I create a instance of a class inside a class member function and assign it to a local variable the instance is not directly destroyed when this member function is left as it was before this update. See the following example code:
Option Explicit
Class CTest
Sub Class_Initialize
WScript.Echo Timer & ": CTest::Class_Initialize()"
End Sub
Sub Class_Terminate
WScript.Echo Timer & ": CTest::Class_Terminate()"
End Sub
End Class
Class CFoo
Sub Work
WScript.Echo Timer & ": CFoo::Work() started"
DoWork
WSCript.Sleep 3000
WScript.Echo Timer & ": CFoo::Work() done"
End Sub
Sub DoWork
WScript.Echo Timer & ": CFoo:oWork() started"
Dim obj
Set obj= New CTest
WScript.Echo Timer & ": CFoo:oWork() done, CTest::Class_Terminate() should be called now without delay"
End Sub
End Class
Dim objFoo
Set objFoo= New CFoo
objFoo.Work
WScript.Echo Timer & ": objFoo.Work() done"
When executing using cscript.exe the following output is generated:
80547,52: CFoo::Work() started
80547,52: CFoo:oWork() started
80547,52: CTest::Class_Initialize()
80547,52: CFoo:oWork() done, CTest::Class_Terminate() should be called now without delay
80550,52: CFoo::Work() done
80550,52: CTest::Class_Terminate()
80550,53: objFoo.Work() done
When executing with a prior version of vbscript.dll the output looks correct like this:
79971,76: CFoo::Work() started
79971,76: CFoo:oWork() started
79971,76: CTest::Class_Initialize()
79971,76: CFoo:oWork() done, CTest::Class_Terminate() should be called now without delay
79971,76: CTest::Class_Terminate()
79974,76: CFoo::Work() done
79974,76: objFoo.Work() done
I think this will lead to problems in any kind of code that count on the fact that objects referenced by local variables are destroyed when the scope is left.
The same bug is there on Windows 7 since KB4524535 (November 12, 2019 (Monthly Rollup)).
Is there any reason for this change in this behavior? I hope there will be a bugfix for this soon...
Regards,
Steffen.
Continue reading...
there seems to be a bug in vbscript.dll since cumulative update KB4524570 for Windows 10 1903. When I create a instance of a class inside a class member function and assign it to a local variable the instance is not directly destroyed when this member function is left as it was before this update. See the following example code:
Option Explicit
Class CTest
Sub Class_Initialize
WScript.Echo Timer & ": CTest::Class_Initialize()"
End Sub
Sub Class_Terminate
WScript.Echo Timer & ": CTest::Class_Terminate()"
End Sub
End Class
Class CFoo
Sub Work
WScript.Echo Timer & ": CFoo::Work() started"
DoWork
WSCript.Sleep 3000
WScript.Echo Timer & ": CFoo::Work() done"
End Sub
Sub DoWork
WScript.Echo Timer & ": CFoo:oWork() started"
Dim obj
Set obj= New CTest
WScript.Echo Timer & ": CFoo:oWork() done, CTest::Class_Terminate() should be called now without delay"
End Sub
End Class
Dim objFoo
Set objFoo= New CFoo
objFoo.Work
WScript.Echo Timer & ": objFoo.Work() done"
When executing using cscript.exe the following output is generated:
80547,52: CFoo::Work() started
80547,52: CFoo:oWork() started
80547,52: CTest::Class_Initialize()
80547,52: CFoo:oWork() done, CTest::Class_Terminate() should be called now without delay
80550,52: CFoo::Work() done
80550,52: CTest::Class_Terminate()
80550,53: objFoo.Work() done
When executing with a prior version of vbscript.dll the output looks correct like this:
79971,76: CFoo::Work() started
79971,76: CFoo:oWork() started
79971,76: CTest::Class_Initialize()
79971,76: CFoo:oWork() done, CTest::Class_Terminate() should be called now without delay
79971,76: CTest::Class_Terminate()
79974,76: CFoo::Work() done
79974,76: objFoo.Work() done
I think this will lead to problems in any kind of code that count on the fact that objects referenced by local variables are destroyed when the scope is left.
The same bug is there on Windows 7 since KB4524535 (November 12, 2019 (Monthly Rollup)).
Is there any reason for this change in this behavior? I hope there will be a bugfix for this soon...
Regards,
Steffen.
Continue reading...