By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,138 Members | 1,249 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,138 IT Pros & Developers. It's quick & easy.

Can reading (not writing) a bad pointer cause the program to crash later ?

P: 4
Hello,

Let’s assume the following piece of code :

void f9 ()
{
char* c= "Could not execute f9";
throw c;
}

try
{
f9 ();
}
catch (char* c)
{
char message[4096];
sprintf (message, "Exception : %s", c);
cout << message;
}
This code works fine, its output is : "Exception : Could not execute f9".

Nevertheless, in the catch clause, the pointer c is indeterminate, the pointee may have been lost.

About such indeterminate (or “bad”) pointers, I have read the following :

If you are lucky, the dereference operation will crash or halt immediately (Java behaves this
way). If you are unlucky, the bad pointer dereference will corrupt a random area of
memory, slightly altering the operation of the program so that it goes wrong some
indefinite time later.
http://cslibrary.stanford.edu/102/PointersAndMemory.pdf
It seems I am unlucky, since my program has not crashed immediately.
But my question is : can it crash later because of this illicit dereferencing ?

In this case, I do not write in the area of memory pointed by by undeterminate pointer.
I only read it.

So, in such a case, can really the memory be corrupted so that my program may crash later ?

Thanks a lot for your ouputs
Apr 22 '09 #1
Share this Question
Share on Google+
11 Replies


100+
P: 687
It is not lost as it's a constant string; It is not destroyed with f9 scope.
And yes, reading memory that doesn't belong to your program will cause program termination.
Apr 22 '09 #2

P: 4
thanks for your response, newb16, but in the catch clause of my program, we are no longer in f9 scope, so, there, it should be lost, isn't it ?
Apr 22 '09 #3

Banfa
Expert Mod 5K+
P: 8,916
Strictly speaking reading an indeterminate pointer location is undefined behaviour. That means anything can happen including the program running as expected and demons flying out of your nose. What actually happens may change for what appears to be a completely unrelated event on the system.

Undefined behaviour should be avoided at all costs.

as newb16 pointed out though you you are returning an indeterminate pointer, it is a pointer to a constant string. What you should be doing is throwing and catching const char * to reflect the constness of the string.
Apr 22 '09 #4

P: 4
@Banfa
Thanks for your response, Banfa

I know that undefined behavior should be avoided, no problem with that.

But can you give me some insight about how reading such an indeterminate pointer can cause the program to crash later (after the reading of the pointer) ?

Thanks in advance for your help
Apr 22 '09 #5

P: 4
@Banfa
Here is what one can read about that in the book "More Effective C++" :

char *p = "Hello"; // non-const pointer, // non-const data

const char *p = "Hello"; // non-const pointer, // const data

char * const p = "Hello"; // const pointer, // non-const data

const char * const p = "Hello"; // const pointer, // const data

https://www.lenep.uenf.br/~bueno/Dis...EC/EI21_FR.HTM
According to the °C++ standard, the type of "Hello" is const char [], a type that's almost always treated as const char*. We'd therefore expect it to be a violation of const correctness to initialize a char* variable with a string literal like "Hello". The practice is so common in C, however, that the standard grants a special dispensation for initializations like this. Nevertheless, you should try to avoid them, because they're deprecated. ¤
https://www.lenep.uenf.br/~bueno/Dis...EC/EI21_FR.HTM
Could you clarify (I am a bit lost) ?

Thanks again
Apr 22 '09 #6

Banfa
Expert Mod 5K+
P: 8,916
Yes, "Hello" is stored as part of the programs const data that is data used by the program that is known to be constant. This includes all string literals plus and any variables declared as const in the global scope.

However whether the const data is actually stored in physically unchangeable store or not is system dependent. For instance most PCs (MAC, Linux or Windows) store all data in RAM allocated from the system and so even the const data is stored in a memory location that is actually writeable, where as most embedded systems will store const data in the systems ROM (or more typically today EEPROM) so this data will be physically not writeable in the normal course of a program (of course will EEPROM you can always go the erase-rewrite route but that is not a simple assignment).

Because of that some C compilers for systems like PCs where everything is stored in RAM give "Hello" the type char * (or the systems char equivalent i.e. TCHAR * on Windows) where as others treat "Hello" as const char * even on systems where "Hello" is stored in RAM (for instance gcc I believe).

The only safe and portable thing to do is to treat string literals as constant, i.e. const char *.

However the C++ standard allows char *p = "Hello"; in order not to break the large body of C code out there that still assumes that string literals are not constant. But as your posted quite says that is deprecated behaviour, in new programs you should always treat string literals as const char *.
Apr 22 '09 #7

Banfa
Expert Mod 5K+
P: 8,916
@jmnat
I don't need to, once the program has invoked undefined behaviour it is in trouble. There is no need or point in trying to work out how it might be in trouble as this could vary from system to system and compiler to compiler.
Apr 22 '09 #8

Expert 100+
P: 2,404
I suggest the following construction for defining c:
Expand|Select|Wrap|Line Numbers
  1. static const char * const c = "Could not execute f9";
"static" makes pointer c persistent beyond the scope of f9; the two "const" may be overkill, but they help to make sure that the value of c and the contents of the string are stable.
Apr 22 '09 #9

P: 1
jmnat,

Reading the pointer cannot make the program crash in a delayed fashion. Seems that the discussion here was misdirected due to your example code which, depending on the compiler, may or may not show the issue you were wanting to illustrate.

Either the pointer will point at an address which is not mapped by the processor (or is mapped to a page that your program is not allowed to access), in which case a page fault will result and your program will crash immediately you dereference the pointer.

Or the pointer will point to an address which is mapped and you'll get away with it.

The text you quoted talks about 'bad pointer dereference', but the author has assumed (without clearly stating so) that the dereference is for a write operation - hence the confusion.
Apr 23 '09 #10

Banfa
Expert Mod 5K+
P: 8,916
kanoop, what you say is limited and in no way covers the full range of possibilities.

I would grant that on a PC to 2 possible outcomes you mention are the most likely but the truth is as I have already stated, undefined behaviour has been invoked and you have no real control or idea of what will happen in the future.

There are many systems that do not produce a page fault or memory exception if an out of bounds memory access is made, you just get random data on the data bus so you are not guaranteed a memory exception but if your program is expecting a specific type of data that it does not get because of the random nature of the return value then when it tries to use that data in the future it may well have a exception of a different type.

Further there are many pieces of hardware that change state when they are read. If your out of bounds point was accidentally pointing at a piece of system hardware and you read it and changed its state to an unknown one then it is hard to say what effect that would have on the future operation of the program although it is unlikely to be good.
Apr 23 '09 #11

Expert 100+
P: 2,404
kanoop:
Another (albeit unlikely) way to get a delayed effect can be seen by examining the catch function. Once the pointer value is corrupted there is some possibility that sprintf will overflow the message buffer. Buffer overflow of this sort is a common exploit used by malware to infect systems. There might not be noticeable symptoms of this fault for several days ... when the Conficker mastermind switches your computer into bot-zombie mode.

@jmnat
Apr 24 '09 #12

Post your reply

Sign in to post your reply or Sign up for a free account.