Quantcast
Channel: LabWindows/CVI topics
Viewing all articles
Browse latest Browse all 5369

case study: data type bug in the code... watch out!

$
0
0

I ran into a code bug that took a while to figure out and I thought I'd pass along the story to warn others.

 

The following pseudo code contains the bug.  The symptom was that mid-execution, the value of position was getting corrupted and thus causing a GPF at the sprintf.

 

 

int CVICALLBACK ServoAutoCalibrate (int panel, int control, int event, void *callbackData, int eventData1, int eventData2)
{
	float pwm;
	int position;
	int timerInterval, timerState;
	switch (event)
	{
		case EVENT_COMMIT:

			GetAsyncTimerAttribute(ljAsyncTimer, ASYNC_ATTR_INTERVAL, &timerInterval);
			for (int k=0; k < CAL_AVERAGE_SIZE * timerInterval; k++)
			{					
				GetAsyncTimerAttribute(ljAsyncTimer, ASYNC_ATTR_ENABLED, &timerState);
				if (timerState == OFF)
					break;
				// delay a bit more than the timer period
				DelayWithEventProcessing(timerInterval * 1.01);
			}sprintf(statusStr, 
					  "Old value = %1.3f pwm",
						systemConfig.servoDuty[position]);
			MessagePopup(statusPanel, statusStr, MESSAGE_NORMAL);
			break;
	}
	return 0;
}

See the bug?

 

 

I had mistakenly declared timerInterval as an int, rather than a double.  And because I'm not in the habit of error-checking the CVI standard library, the call to GetAsyncTimerAttribute blindly overfilled timerInterval with its double value, which then overwrote the value of position.

 

position was the collateral damage because it's declared before timerInterval.

 


Viewing all articles
Browse latest Browse all 5369

Latest Images

Trending Articles



Latest Images

<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>