GPF in graph zooming

[Wolfgang]

Hi,

I have a graph control, created in the GUI editor (CVI 9.0), control mode normal, data mode retain, zoom style rectangle. If the check mark in the GUI editor 'copy original plot data' is not checked, a GPF occurcs if a graph is zoomed in. This can be avoided by setting this check mark. Unfortunately, this is not mentioned anywhere in the documentation. There is a related forum contribution for CVI 6/7, but in my opinion the GUI editor should not permit settings that lead to program crashes.

If the data need to be retained for zooming, then choosing a zoom style the check mark should be set automatically. Furthermore, it should be added to the help file.

Anyway, best wishes for 2009, Wolfgang

[LuisG]

Hi Wolfgang,

It's not a given that disabling "copy original plot data" will cause a crash when you zoom the graph. It all depends on what you do with the data buffer that you pass to the plotting function after you plot. This is an advanced feature that can be used to save memory, but you can only use it in some very specific circumstances: either the graph will never rescale after you plot the data, or if it does rescale, you still have the original data buffer allocated in your program, with the same data in the buffer.

If you view the help for that control, it does say that "erroneous results might occur if you change or deallocate the data". There's some additional information on this in the "Programming with Graph Controls" help topic (right-click on a graph control in the UI editor, select "Control Help", then click on the "Programming Graph Controls" link. Read the "Optimizing Memory Usage" section).

Please do let me know if you are having a crash even though you have not deallocated the buffer.

Thanks,

Luis

[Wolfgang]

Hi Luis,

actually, this is not a problem for me as I am well aware of this 'risk'... And to answer your question, yes, the GPF only happens if the data memory is deallocated. Still, I would suggest changing the zoom subroutine to first check if all the data pointers are still valid. If not, it could return without doing anything. Still much better than crashing. A GPF is a GAU and should be avoided, IMHO.

[LuisG]

Does the crash happen both in debug and release modes? In release mode, it isn't really possible to check the validity of pointers, since there is no pointer information built into the executable. I think that in debug mode CVI does check the validity of the pointers.

Luis

[Wolfgang]

Hi Luis,

1) the crash happens while running in debug mode (and extended debugging level).

2) I agree that it is not possible to find out if a pointer is valid or not, but it might be possible to check the data pointers if they are NULL. For example, to free dynamically allocated memory I use

    free ( *memory_block_pointer );
    *memory_block_pointer = NULL; 

This permits me to use a function for memory allocation or reallocation, simply by checking if the pointer is NULL (then alloc), otherwise, if data already exist, use realloc. 

Your function could behave in a similar way, check if the data pointer is NULL (danger -> do not do anything). This will not avoid all problems (e.g. if memory has been freed without the NULL assignment), but reduce the number of possible complications. 

Wolfgang

[LuisG · Accepted solution]

HI Wolfgang,

1) I would not have expected it to crash in debug mode. I've created an internal bug report to track this issue (ID: 139151).

2) I agree that it's a good idea to clear pointers after you free them, but in that case that can't prevent this problem. If your sequence looks like this:

data = malloc (...);

// populate data

PlotY (..., data, ...);

free (data);

data = NULL;

If you passed the real pointer to the PlotY function, that's the only information that the graph control has. Changing the value of the variable that holds the pointer later on will not have any effect on the graph control, since the graph control has no access to this variable.

Luis

[Wolfgang]

Hi Luis,

you are right - sorry...