Are you sure you're calling the function on a valid object? Are you sure that all pointers and references in the surrounding/calling code are valid? Are you sure nothing is getting prematurely destroyed, or unexpectedly copied or assigned? Do the classes involved follow the rule of three?
This is all called on a VertexBuffer object directly that gets constructed within the same scope, prior to the new call in the function I provided all values are correct as soon as the new is done the value in the passed parameter is wrong. I found this out with a databreak point on the location that gets changed.
The vertex buffer class itself has no virtual methods and relies on compiler generated assignment operator and copy constructor. IN the calling code we don't assign the vertexbuffer to a new object we only pass the pointer to a container and manager class. So copy construction and assignment are out in this case. Besides it would be weird if in unoptimised code a copy or assignment would happen during a call to a private method from a public one, you wouldn't be able to trust your application flow anymore, ow and before you ask this code is single threaded.
I should have mentioned this earlier but the function is a private method of the class that gets called from a public function that passes it it's data which comes from the calling function and the overwritten param is on the stack there as well(actually on the line above the public function call of the vb object) and directly passed into this function.