[python-win32] Memory access violation using pywin32 as WSH

[Mark Hammond]

It's been years since I've looked at this, but IIRC, a "script item" is 
whatever the host wants it to be - eg, in a HTML page, it would be 
anything between <script></script> tags. I believe WSH would just use 
one for a script file.

The Close() method will generally be called by the host - not calling 
this could cause a memory leak (particularly if the COM reference count 
also didn't hit zero), but it shouldn't cause a crash. That said though, 
I certainly would not rule out a bug in pywin32's implementation.

The absolute best thing for us would be to reproduce the crash in the 
test code at 
https://github.com/mhammond/pywin32/tree/main/com/win32comext/axscript/test. 
The next best thing would probably be a stack trace of the crash.

Cheers,

Mark

On 29/11/2022 10:38 am, Bob Kline wrote:
> On Mon, Nov 28, 2022 at 4:12 PM Bob Kline <bkline at rksystems.com> wrote:
>> ....
>> Perhaps, for example, I'll be able to find something which is supposed
>> to get released at application shutdown time but which isn't. ....
> 
> I've added some debug logging to the top of most methods in
> pyscript.py, mostly just announcing that the method was invoked. I was
> a little surprised to find that for each invocation of the macro seven
> instances of the ScriptItem class were created, instead of just one.
> So clearly I have yet to figure out exactly what a ScriptItem is. The
> really interesting thing is that if I invoke the macro once for a
> given run of the host application, the ScriptItem.Close() method is
> called seven times, matching the seven times the ScriptItem
> constructor is hit. However, if the macro is invoked twice for a run
> of the host application, I still see only seven calls to
> ScriptItem.Close(), even though there are now fourteen calls to the
> ScriptItem constructor. Can I assume that this is a problem? Sure
> smells like one. Where does the responsibility for calling the Close()
> method ultimately fall?
>