Highlighted
New Member.
1850 views

Best Practices for using variables while developing script in VuGen

Jump to solution

Hi 

Can anyone let me know best practices for using variables while developing script in Vugen

Regards

Pinnk

0 Likes
1 Solution

Accepted Solutions
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: Best Practices for using variables while developing script in VuGen

Jump to solution

No, it will not fix memory-leaks!!!

But if you use alloc()/malloc() and not give it back with free() you will CREATE a memory leak. So to mostly use LoadRunner variables you will avoid creating (one type of) them.

br /ola


Please mark post as solved if your problems or questions is/are resolved.
If this post was valuable to you, please consider kudo it.

 

.

View solution in original post

0 Likes
4 Replies
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: Best Practices for using variables while developing script in VuGen

Jump to solution

Hi

No, there is no widely used best practice helping you here.

Is it something special that concerns you?

Is it LoadRunner varibles or the c-variables?
Generally speaking, it is easier to use the built in LoadRunnner variables if you are not an experienced LoadRunner /C-programmer. Then you don't need to worry about the Garbage collection. With C-variables and using malloc() and free() you need to be 100% certain of what you do to not create memoryleaks or get memory access violation that can crash the test.

br /ola


Please mark post as solved if your problems or questions is/are resolved.
If this post was valuable to you, please consider kudo it.

.
0 Likes
Highlighted
New Member.

Re: Best Practices for using variables while developing script in VuGen

Jump to solution

Hi

How t fix memeory leak in loadrunner,Does the declaration of variables effect that??

Regards

Pinnk

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: Best Practices for using variables while developing script in VuGen

Jump to solution

No, it will not fix memory-leaks!!!

But if you use alloc()/malloc() and not give it back with free() you will CREATE a memory leak. So to mostly use LoadRunner variables you will avoid creating (one type of) them.

br /ola


Please mark post as solved if your problems or questions is/are resolved.
If this post was valuable to you, please consider kudo it.

 

.

View solution in original post

0 Likes
Highlighted
Super Contributor.
Super Contributor.

Re: Best Practices for using variables while developing script in VuGen

Jump to solution

Memory leaks are always hard beasts - and one of the reasons why C has become somewhat of a niche programming language. 

As Ola points out, Vugen will not "fix" C code for you. If your C code allocates more and more memory and never releases it, your programs will experience running out of memory. The typical fix for this one of two:

(a) If are able to, put code in functions or { blocks } and use local variables and exit from the functions once in a while (i.e., if you opt for recursive functions, you should know what you are doing).

(b) Go the route using malloc()/free() calls - but in my experience, your ACTUAL C code in Vugen scripts very seldom is so large and long running, this makes sense.

So basically, keep track of which C functions are allocating memory and handle them accordingly.

 

Of course, when you are fairly sure your C code is fine, please do not forget some of the LoadRunner functions like lr_eval_string() will allocate memory without ever freeing it. Just as a fun experiment, try a Web HTTP/HTML protocol script like the below and try running it overnight. Monitor the memory usage of the machine you are running the script on:

vuser_init()
{
  lr_save_int(17, "N");
  for (;;) { /* for ever */
    char *p;
    p = lr_eval_string("{N}"); /* do not actually do anything */
  }
}

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.