From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
01-29-2010 03:35 PM
Hello,
I have the problem that in my CAN - Application the following error appears: Dereference of out-of-bounds pointer
The debugger marks the following variable in this text line: if (cmsg_rx[i].id > 384 && cmsg_rx[i].id < 640 && cmsg_rx[i].len <= 😎
This error does not appear always, only sometimes but then in series when trying to run the program. Later, I can start and exit the program without problems.
In one file, the array is defined as CMSG cmsg_rx[2047]; and in the function where the error appeares as extern CMSG cmsg_rx[];
How can I avoid this error?
01-30-2010 02:16 AM
01-30-2010 03:56 AM
01-31-2010 03:39 PM
This is strange: 0 is a valid value for an array index, you should not get this error with such an index.
Are you sure you have this index value when you get the error?
01-31-2010 04:13 PM
02-02-2010 05:39 AM
02-04-2010 06:41 AM
Now, I have new findings in my problem. Because of wondering about the fact thar error only appears ins debug configuration, I deleted the file projectname_dbg.cdb and the directory cvibuild.projectname. From this point on, I can execute the program in debug mode a few times then the error appears again. I do not really understand this. Is it possible that the error is evocated by CVI?
I can shorten my program to the minimum and post the code which makes the error.
Thank you very much for helping me!
02-04-2010 07:38 AM - edited 02-04-2010 07:40 AM
When you delete those elements, you force the compile to rebuild the debug executable from the source code, whereas if you simply re-run a project in the IDE without modifying anything actual debug executable is used as is. This should be the same as using Build >> Mark project for recompilation menu option.
It is not clear to me why the program runs a few time without -apparently- any modification before the error starts rising: looking at your code could help to find a reason and a solution, if you can narrow down it to a subset that still offers this erratic condition.
One last question: is the byte count in error message always the same of it varies randomly? In the first case I would be prone to look for some repetitive condition that generates the error while in the second I'd start by lookong for some unizialized index or something similar to this.
03-26-2010 08:08 PM
Roberto Bozzolo wrote:When you delete those elements, you force the compile to rebuild the debug executable from the source code, whereas if you simply re-run a project in the IDE without modifying anything actual debug executable is used as is. This should be the same as using Build >> Mark project for recompilation menu option.
It is not clear to me why the program runs a few time without -apparently- any modification before the error starts rising: looking at your code could help to find a reason and a solution, if you can narrow down it to a subset that still offers this erratic condition.
One last question: is the byte count in error message always the same of it varies randomly? In the first case I would be prone to look for some repetitive condition that generates the error while in the second I'd start by lookong for some unizialized index or something similar to this.
Message Edited by Roberto Bozzolo on 02-04-2010 02:40 PM
I ran into this problem too and was pulling my hair out. Recompiling everything seems to have worked.
04-08-2010 01:37 PM
To me this appears to be a classic example of an uninitialized variable. I know you say you have the index variable initialized but I can't think of anything else that would result in this error.
I personally have a policy of initializing EVERYTHING when I declare it, even if I know I am going to initialize it programmatically right away.
You will never see me write something like:
int i;
it will always be:
int i = 0;
Starting from a known state is invaluable. I cannot tell you how much trouble I had finding initialization problems prior to adopting that practice. It is a very good habit to get into and can save you a lot of hair pulling.
I also highly recommend enabling the following build options:
Detect uninitialized local variables at run-time
Detect unreachable code
Detect unreferenced identifiers
Set Uninitialized local variable detection to Agressive