Oleg,
You are absolutely right, pMatList is not big enough. And what was really
happenning was that the variables that were allegedly being "deleted" or "set
to NULL" were being somehow modified by going out of pMatList bounds.
After all these years I keep falling in the same trap :(
Thanks for your suggestions, I greatly appreciate your time helping me!
Cheers,
~Bilbao
[quoted text, click to view] "Oleg Starodumov" wrote:
>
> It looks like a write past the end of an array allocated on the stack
> (as a local variable).
>
> Without seeing the code for the whole function, I would suspect
> that pMatList could point to a local array, whose size is not big enough
> to contain 27 (28?) elements.
>
> While debugging, you can try to catch it in the following way:
>
> 1. When entering the function, determine the address of the variable
> that is being corrupted (pAttributeTable, or pMesh) (e.g. enter "&pMesh"
> in Watch window to determine the address).
>
> 2. After the value of the variable has been initialized, set a data breakpoint
> at the address of the variable (use "Data" tab in New Breakpoint dialog,
> and after closing the dialog make sure that the breakpoint's checkbox is checked
> in Breakpoints window).
>
> 3. Step through the function and wait until the breakpoint is hit.
> The execution will stop at the line that wrote to the variable,
> or at the next line after it. Now you can see exactly who changes the value
> of the variable.
>
> 4. Disable the breakpoint after control leaves the function, since this place
> on the stack can be reused and can cause false alarms (breakpoint hits).
>
> Or, without using a data breakpoint, simply step through the function's code
> and see where the value of the variable is changed.
>
> Also it makes sense to build the project with /RTC1 (debug build only)
> and /GS compiler options (note that these options help to detect various
> stack-related problems, but they also change the layout of the stack,
> so if they are not yet enabled, it might be better to enable them only after
> you have fixed this particular problem)
>
> Regards,
> Oleg
>
>
>
>
>
>
It looks like a write past the end of an array allocated on the stack
(as a local variable).
Without seeing the code for the whole function, I would suspect
that pMatList could point to a local array, whose size is not big enough
to contain 27 (28?) elements.
While debugging, you can try to catch it in the following way:
1. When entering the function, determine the address of the variable
that is being corrupted (pAttributeTable, or pMesh) (e.g. enter "&pMesh"
in Watch window to determine the address).
2. After the value of the variable has been initialized, set a data breakpoint
at the address of the variable (use "Data" tab in New Breakpoint dialog,
and after closing the dialog make sure that the breakpoint's checkbox is checked
in Breakpoints window).
3. Step through the function and wait until the breakpoint is hit.
The execution will stop at the line that wrote to the variable,
or at the next line after it. Now you can see exactly who changes the value
of the variable.
4. Disable the breakpoint after control leaves the function, since this place
on the stack can be reused and can cause false alarms (breakpoint hits).
Or, without using a data breakpoint, simply step through the function's code
and see where the value of the variable is changed.
Also it makes sense to build the project with /RTC1 (debug build only)
and /GS compiler options (note that these options help to detect various
stack-related problems, but they also change the layout of the stack,
so if they are not yet enabled, it might be better to enable them only after
you have fixed this particular problem)
Regards,
Oleg
