Re: [python-win32] Memory access violation using pywin32 as WSH
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 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 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? ___ python-win32 mailing list python-win32@python.org https://mail.python.org/mailman/listinfo/python-win32
Re: [python-win32] Memory access violation using pywin32 as WSH
On Mon, Nov 28, 2022 at 4:12 PM Bob Kline 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? -- Bob Kline https://www.rksystems.com mailto:bkl...@rksystems.com ___ python-win32 mailing list python-win32@python.org https://mail.python.org/mailman/listinfo/python-win32
[python-win32] Memory access violation using pywin32 as WSH
We've got a project we've supported for many years which involves
using XMetaL (a commercial XML editor) customized with macros written
in JScript. The vendor claims that the scripting "can use any
scripting language that conforms to the Microsoft Scripting Language
Interface." Since JScript is much more restricted in what it can do,
and since our team is much more familiar with Python than with
JScript, we would like to switch to Python for our scripts. However, a
dirt-simple proof of concept fails with a memory access violation. We
created a macro file with a single macro which displays an alert box
with a simple string. If the lang attribute for the macro element (the
macros are stored in an XML file, with the code for each macro stored
in a MACRO element) is set to "JScript" the macro can be run an
unlimited number of times without any problems. If the lang attribute
is set to "Python" (the macro is so simple that the syntax is
identical for the two languages) the macro can be run once without any
apparent problems, as long as you close the XMetaL application and
launch it again before the next run of the macro. However, if XMetaL
is launched and the macro is run twice or more before shutting down
the application, it is no longer possible to launch it again until the
user logs off the machine and logs back in. When the user logs off, a
dialog box appears reporting a memory access violation ("xmetal.exe -
Application Error. The instruction at referenced
memory at . The memory could not be read."). To be
clear — the macro does what it's supposed to (display a dialog box
with a string) each time it is run. The problem only manifests itself
when trying to launch the application again or when logging off the
machine. Interestingly, when the application is in this "I can't be
launched again and I will report a failure at logoff time" state there
is no evidence that the process is still hanging around. It doesn't
show up in Process Manager, for example. But it seems clear from the
title bar of the error dialog that it's coming from the application.
At this point I don't know for sure whether the problem is caused by
something the XMetaL application is doing wrong (and presumably
differently than what it does when the scripting engine is JScript) or
by something that pyscript.py is doing. I am aware that I could easily
get caught between two projects, each of which claims that the failure
must be caused by the other. I have reported the problem to the XMetaL
support team and I am waiting to hear what they have to say. I'm
hoping that the data point of "one macro invocation succeeds, two
macro invocations fail" provides a useful clue.
What would be helpful from the pywin32 team's side would be any
suggestions you might have for how I might go about tracking what's
going on, presumably by hacking pyscript.py and/or framework.py in
win32comext/axscript/client to add logging to the file system.
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'm
still trying to absorb the axscript/client code and wrap my head
around what the processing flow is and what the different classes are
doing.
Any clues for where to start? Anyone else run into similar memory
access violations using Python as a Windows Scripting Host?
Many thanks!
--
Bob Kline
https://www.rksystems.com
mailto:bkl...@rksystems.com
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32
