I think there are memory leaks of the compiled program in case runWindow == NULL (aka macro checking). And for the case runWindow != NULL and runWindow->macroCmdData != NULL I'm not sure.
I think I have an idea, how to prevent this memory leak, of the just compiled program (which are run with RunMacroAsSubrCall):
before setting up the new frame for this program, setup a pseudo frame, which has as code a function which free the program on top of the stack, and push the to be run program onto the stack. Therefore, if the program returns, this pseudo stack is executed, which frees the program.
Ok, here is a patch:
it calls FreeProgram() in the case runWindow == NULL.
The other case is not a leak, because runMacro() is responsible for freeing the prog.
This is only a smal step, as pointed out in some new comments there are more leaks.
File Added: fix-memleak-in-readCheckMacroString.patch.txt
This is an implementation of my 'pseudo frame' idea. Patch applies after disable-FreeProgram.patch.txt from BUG#2113904 (which applies after fix-memleak-in-readCheckMacroString.patch.txt).
File Added: FreeProgram-after-RunMacroAsSubrCall.patch.txt
fix leaks for RunMacroAsSubrCall()
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.