[OpenSTA-devel] [ opensta-Bugs-1598629 ] Using SCL SUBROUTINEs causes memory corruption

[SourceForge.net <no...@so...>]

Bugs item #1598629, was opened at 2006-11-17 16:57
Message generated for change (Comment added) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1598629&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Script Language
Group: Serious
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Danny Faught (faught)
>Assigned to: Daniel Sutcliffe (dansut)
>Summary: Using SCL SUBROUTINEs causes memory corruption

Initial Comment:
Subroutine calls that pass parameters cause a memory leak in TExecuter_htp.exe and the Script Modeler.  This is severe enough in some cases that we have to manually set variables instead of using parameters in a subroutine call to pass data into a subroutine.

I'm running OpenSTA 1.4.3.20 on Windows XP Pro SP2.  Sample code that quickly demonstrates the leak when running under a single VU is below.

---------------------
!Browser:IE6
!Date : 4/20/2006
Environment
	Description ""
	Mode		HTTP
	Wait		UNIT MILLISECONDS

Definitions
	integer loop
	character*8192 foo
	
Code
	do loop = 1, 2, 0
		do loop = 1, 1000
			call makeleak ["aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"]
		enddo
		wait 1
	enddo

subroutine makeleak [foo]
end subroutine
---------------------

Warning: the Script Modeler tends to become unresponsive when running this script.

----------------------------------------------------------------------

>Comment By: Daniel Sutcliffe (dansut)
Date: 2006-12-11 20:11

Message:
Logged In: YES 
user_id=19748
Originator: NO

A reasonable amount of evidence has been collected that suggests that
using any SUBROUTINE calls causes memory corruption - and this memory
corruption can lead to memory leaks and/or tests failing/crashing.  Using
parameters in SUBROUTINE calls seems to guarantee memory leaks but this is
only part of this much bigger problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1598629&group_id=10857