LoadRunner VuGen: What’s Up With SPRINTF?

In my custom load testing class, we usually get into specific code examples that demonstrate how to do some tips and tricks in VUGen. One of the things I always like to bring up is the behavior or sprintf. This is a commonly used C function for string manipulation. Many a young LoadRunner lad has come across the dreaded memory violation error in their output log when using sprintf:

Error: C interpreter run time error: Action.c (10): Error — memory violation : Exception ACCESS_VIOLATION received.

Let’s look at why. Here is some code:

----begin code----
int VuserId = 1;
char *GroupName = "Group1";
char TestLoginName[100] = "ScottMoore";
sprintf(TestLoginName, "pTestuser%d%s", VuserId, GroupName);
lr_save_string(TestLoginName, "LoginParam");
lr_output_message("The new variable is called %s", lr_eval_string("{LoginParam}"));
return 0;
----end code----

We’re declaring an integer variable, a character pointer, and a character array. Then we’re using sprintf to put them all together as a new LoadRunner parameter type, and finally sending a message to our output window to tell us the name of the new parameter. Paste this into a script and it will run with no problem.

Now let’s change the line

char TestLoginName[100] = "ScottMoore";

to

char *TestLoginName = "ScottMoore";

Just for kicks, hit the COMPILE button in VUGen. No errors. We must be in the clear, right? Wrong. Running the script will give you that memory violation error as listed above. Why? The initial space for the ScottMoore\0 that is allocated for the char * is given in CODE area of the executable. The CODE area may not be modified. By changing the variable to a pointer, you’re essentially reserving only 11 bytes (10 characters in the name, plus the 0 terminator). That means there isn’t any room to add the other elements (the VuserID and GroupName). Thus, you get an ACCESS_VIOLATION because sprintf is trying to write to memory it shouldn’t. We could go into a discussion about the fact that there is no such thing as a string in C, but that is a different blog posting. My point is simple: Understanding VUGen means you need to have a good understanding of C and the role VUGen plays as an interpreter/compiler.

I wish to thank Russell Van Steenburgh at the Script Farm, and Mark Sechrest for helping me be able to explain this to mere mortals like myself. :)

What's Next?

Did you enjoy this article? Help spread the word by sharing:

Join the Northway Navigator Club today and get access to restricted content including our best tips and tricks. Membership is free! You will also receive free email updates by registering.

Engage in the conversation and leave a comment:

Scott Moore

About Scott Moore (153 articles)

With over 20 years of IT experience with various platforms and technologies, Scott has tested some of the largest applications and infrastructures in the world. He is a Certified Instructor and Certified Product Consultant in HP’s LoadRunner and Performance Center products. He currently holds HP certifications for ASE, ASC, and CI. A thought leader in the APM space, he speaks regularly at IT conferences and events



  • Jake

    I’m confused about your statement ”
    the fact that there is no such thing as a string in C”
    .  A “string” is just an array of characters, what am I missing here?  Do you mean string object?

    • http://www.northwaysolutions.com/ Scott Moore

      Yes, that is what I meant. As opposed to the string variable we have in JAVA. I read that statement in a C book a long time ago, and that we should always think in terms of character arrays, not “strings” as some more modern languages define it. Modern being anything younger than C. LOL!