08-18-2005 06:03 AM
At the point the debugger halts on the GPF, what is the value of the loop counter channelNumber? Is it the first time through the loop, or the last? Is it a value within a range that you expect? Are all the PSPU1PSNum[] elements NULL at this point, or just one?
It may be that some unassociated code is inadvertantly writing into the area that has been calloc'ed and zeroing the pointers - I'm not sure that the CVI Watch system would pick that up.
JR
08-18-2005 07:21 AM
08-19-2005 03:52 AM
As I understand it, your program should halt on the breakpoints in the sequence shown above. The first one will enable you to verify that both the correct number of items (PSPU1Channels) have been allocated, and that all the allocations were successful. (Not NULL.)
The second one will allow you to check that the value of PSPU1Channels has not changed from what you expect (you have already checked that the pointers are unexpectedly NULL, here) at the point where the GPF occurs.
The third one is simply to ensure that there is no inadvertant call to free the memory prematurely - it seems to be the only place in your program that the pointers are explicitly NULLed.
Although the memory sizes involved are sufficiently small so that the static array approach would be a perfectly acceptable alternative design solution to the problematic dynamic approach, it is worth pursuing the bug as it may indicate that your code might not be performing in exactly the way you intended.
JR
08-19-2005 04:17 AM
Hello JR
Many thanks for your suggestions. I have already performed as what you have suggested. But no luck. And what you mentioned about static array approach meantime yesterday i made these modifications and now using static array instead of dynamic since there is not much difference in memory requirement considering the worst case and regular case so decided to use this approach. Now application is working fine. Anyway i will try to sort out this bug. And i will let you know ............
Thanks again...
Rakesh