Why does C/C++ programs crash

[NewToCPP]

Hi,

Why does a C/C++ programs crash?

When there is access to a null pointer or some thing like that programs
crash, but why do they crash?

Thanks.

 

[Ian Collins]

Hi,

Why does a C/C++ programs crash?

When there is access to a null pointer or some thing like that programs
crash, but why do they crash?

What would you suggest as an alternative?

Normally it isn't the program that crashes, but the operating
environment that terminates the program when it attempts to access
something that doesn't belong to it. The contents of address 0 for example.

 

[Phlip]

Why does a C/C++ programs crash?

Firstly, some people post the term "C/C++" when they clearly don't know
the difference between C and C++, so we often correct them.

In this case, you are asking "Why do members of the C family of languages
crash?" That includes various Small-Cs, K&R C, Objective-C, ISO C, ARM
C++, ISO C++, GNU C, GNU C++, and so on. Each just a little different!
They all crash.

(Java and C# are not on the list. They crash for different reasons. {}
for block delimiters does not a C language make!)

When there is access to a null pointer or some thing like that programs
crash, but why do they crash?

Because the C languages were invented to compete with Assembler, which
crashes whenever you write impossible instructions for the CPU. Like
"point to protected memory", or "treat this impossible number as an opcode".

Such crashes invoke hardware protection (or less), so a C language will
simply rely on that hardware.

An assembler cannot read all your machine language opcodes and predict
which ones will cause trouble. Similarly, a C language cannot predict
which sequence of operations will crash. And a C language, by definition,
compiles rapidly to create brute-force assembly code, with very little
interpretation. Without a simple mapping between C constructs and assembly
code, those who need speed could not use a C language.

 

[Scott McPhillips [MVP]]

Hi,

Why does a C/C++ programs crash?

When there is access to a null pointer or some thing like that programs
crash, but why do they crash?

Thanks.

When the program performs such an invalid operation it is unsafe to
proceed. Letting it run would cause further damage. It's just like
having a wheel fall off a car: Do not proceed.

 

[Frederick Gotham]

NewToCPP posted:

Hi,

Why does a C/C++ programs crash?

When there is access to a null pointer or some thing like that programs
crash, but why do they crash?

Thanks.

A general access fault in the second fudiciary conduit on the third branch of
the CPI routing scheme. That's your problem 99% of the time.

 

[Kaz Kylheku]

Firstly, some people post the term "C/C++" when they clearly don't know
the difference between C and C++, so we often correct them.

Microsoft's compiler outputs a message identifying itself as "C/C++".

 

[Ian Collins]

Microsoft's compiler outputs a message identifying itself as "C/C++".

And we all know how well they adhere to standards!

 

[Kai-Uwe Bux]

And we all know how well they adhere to standards!

One of the most standard compliant compiler vendor (even supporting export)
uses

Comeau C/C++ (tm)

to advertise the products. Maybe, when it comes to compilers the
string "C/C++" sometimes means: a pair of two compilers (one for C and one
for C++) that produce binary compatible object files for the use with a
common linker.


Best

Kai-Uwe Bux

 

[peter koch]

Ian Collins skrev:

And we all know how well they adhere to standards!

Some of us do. They are quite standards compliant - the only serious
omission being no support for export.

/Peter

 

[Robbie Hatley]

Why does a C/C++ programs crash?

For the same reason cars crash: people drive them badly.

The most common error in C or C++ is illegal use of resources,
such as:

char* i; // declare pointer i, pointing to God knows what
*i = 7; // write 7 to unknown RAM address; effect unknown

But other errors can cause "crashes", such as:

double A = 3.07;
for (int i = 0; i >= 0; ++i) // runaway loop, never exits
{
A *= 1.035;
}

Or:

// In header1.h:
#include header2.h

// In header2.h:
#include header1.h // Oh, my.

(Crashes spectularly at compile time; preprocessor churns for
a long time, fills both stack and paging memory with crap,
causing system crash due to resource exhaustion. Programmer
should have used include guards.)

The list goes on.

Short answer: programs crash because people make dumb mistakes.

--
Cheers,
Robbie Hatley
Tustin, CA, USA
lonewolfintj at pacbell dot net
(put "[usenet]" in subject to bypass spam filter)
http://home.pacbell.net/earnur/

 

[Jim Langston]

What would you suggest as an alternative?

Normally it isn't the program that crashes, but the operating
environment that terminates the program when it attempts to access
something that doesn't belong to it. The contents of address 0 for
example.

Well, consider this (untested) program.

int main()
{
int MyInt = 10;
int* MyIntP;

MyIntP = &MyInt;

MyIntP = 20; // Ooops, meant *MyIntP = 20 here

std::cout << MyIntP << std::endl;

*MyIntP = 30; // Got syntax right this time, but pointer is wrong
}

What would you suggest this program to do? Given the proper headers it
should compile and run as it is all legal code. But the programmer made a
mistake on one line. Instead of changing the contents of a pointer to a
value, they accidently changed the pointer itself. Then they tried to view
to the contents of the pointer, and then change the contents of the ponter.

What is the computer supposed to do? MyIntP = 20; is legal. There may be
cases where it's actually valid and is what was meant to do. But in this
case it's just wrong logically.

The next line the program is supposed to output the contents at the pointer,
but the pointer is pointing to memory the program doesn't "own". In fact,
depending on how the architecture and OS is set up, it may not even be
pointing to memory at all. What would you have the program do when it gets
to this point? On windows an error message will pop up stating that the
program attempted to read memory it doesn't "own". That is a crash. What
alternative is there?

If that last line was commented out, what would you have the next line do?
It is attempting to write to memory the program doesn't "own" Windows again
pops up with an error, this time saying the program is trying to write to
memory the program doesn't "own".

There are many reasons that the OS doesn't allow you to just write to memory
willy nilly. Mostly because it's usually a bug when you try to do so as
this shows.

Do you have an alternative? Of course, I could put in try ... catch blocks
and catch the errors in my program, but what could I do more than give my
own message saying I'm trying to use memory I don't own? The program
obvoiusly can't continue at this point, because the compiler/OS/program has
no way of knowing if the line that was trying to run was critical to the
program or not.

 

[Ian Collins]

Well, consider this (untested) program.

int main()
{
int MyInt = 10;
int* MyIntP;

MyIntP = &MyInt;

MyIntP = 20; // Ooops, meant *MyIntP = 20 here

std::cout << MyIntP << std::endl;

*MyIntP = 30; // Got syntax right this time, but pointer is wrong
}

What would you suggest this program to do? Given the proper headers it
should compile and run as it is all legal code. But the programmer made a
mistake on one line. Instead of changing the contents of a pointer to a
value, they accidently changed the pointer itself. Then they tried to view
to the contents of the pointer, and then change the contents of the ponter.

What is the computer supposed to do? MyIntP = 20; is legal. There may be
cases where it's actually valid and is what was meant to do. But in this
case it's just wrong logically.

Are you replying to me or the OP?

 

[Howard]

For the same reason cars crash: people drive them badly.

The most common error in C or C++ is illegal use of resources,
such as:

char* i; // declare pointer i, pointing to God knows what
*i = 7; // write 7 to unknown RAM address; effect unknown

But other errors can cause "crashes", such as:

double A = 3.07;
for (int i = 0; i >= 0; ++i) // runaway loop, never exits
{
A *= 1.035;
}

An infinite loop is not a "crash". Infinite _recursion_ would lead to a
crash, but an infinite loop simply loops. I've written programs that loop
forever (well, until I stop them anyway).

Or:

// In header1.h:
#include header2.h

// In header2.h:
#include header1.h // Oh, my.

(Crashes spectularly at compile time; preprocessor churns for
a long time, fills both stack and paging memory with crap,
causing system crash due to resource exhaustion. Programmer
should have used include guards.)

What compiler does that? VS 2003 reports "too many include files: depth =
1024". Sounds like a pretty poorly written compiler if it can't protect
itself from the data it's processing.

And compile-time problems are also not program crashes, (except perhaps in
some cases, a crash of the _compiler_ program).

The list goes on.

Short answer: programs crash because people make dumb mistakes.

There are many reasons, not just dumb mistakes. Removing a required
physical resource, hard disk problems, running out of memory, cosmic rays,
power surges, and even subtle mistakes that aren't "dumb" at all, to name a
few. Any number of things might lead the system to determine that a process
is attempting an invalid operation, and that it needs to shut down the
offending process.

-Howard

 

[Jakob Bieling]

int main()
{
int MyInt = 10;
int* MyIntP;

MyIntP = &MyInt;

MyIntP = 20; // Ooops, meant *MyIntP = 20 here

std::cout << MyIntP << std::endl;

*MyIntP = 30; // Got syntax right this time, but pointer is wrong
}

What would you suggest this program to do? Given the proper headers
it should compile and run as it is all legal code. But the [..]
What is the computer supposed to do? MyIntP = 20; is legal. There

MyIntP = 20; is not legal. The compiler will abort with an error.

hth

 

[Default User]

MyIntP = 20; is not legal. The compiler will abort with an error.

There's no requirement that the compiler abort, nor is there any
requirement for an "error". The only thing the Standard requires is a
diagnostic. The compiler could go ahead and finish compiling if the
designer wanted it to.



Brian

 

[Robbie Hatley]

:

An infinite loop is not a "crash".

That's like saying, "your car caught fire and burned up, Mr. Smith,
so we're sorry, but we can't pay on your claim; you're only insured
against actual CRASHES, not fires". In other words, it crashed.

Infinite _recursion_ would lead to a crash, but an infinite
loop simply loops. I've written programs that loop
forever (well, until I stop them anyway).

Yes: Firmware, and Microsoft Windows apps both "loop forever";
but the loop I demonstrated doesn't just "loop forever", it
does so in a way that precludes input, output, or breaking
out. You generally have to push the "Reset" button. In other
words, it crashed.

(I inadvertantly did that to an IBM 370 for an entire half hour
once. Boy was the sysop annoyed when he discovered the the
entire system had been doing nothing but running my loop for
30 minutes. Good thing they didn't charge me for the CPU time.)

What compiler does that?
VS 2003 reports "too many include files: depth = 1024".
Sounds like a pretty poorly written compiler if it can't
protect itself from the data it's processing.

The situation I describe will crash the preprocessor.
The program will never get to the compiler.

Compilers never see #include's. The preprocessor replaces
those (if it can) with the contents being #include'ed. If
it can't, it crashes, and the compiler never runs.

And compile-time problems are also not program crashes.

That's like saying, "I'm sorry, but we can't pay on your claim
because you crashed your car while it was still inside the car
lot you bought it from." In other words, it crashed.

There are many reasons, not just dumb mistakes. Removing a
required physical resource

Two people made dumb mistakes there: The person who removed
the resource, and the person who made the program so brittle
that the missing resource triggered a crash.

hard disk problems

The user slammed the door into the computer, or the HD engineer
designed a flaky product. In other words, dumb mistakes.

running out of memory

The user ran a resource-hungry program on a machine with only
8MB of RAM. Dumb mistake.

cosmic rays

In other words, someone made a dumb mistake, and cosmic rays
seemed a good thing to blame.

power surges

User forgot to use a surge protector and an UPS, and left his
machine running during a thunderstorm. Dumb mistake.

and even subtle mistakes that aren't "dumb" at all,

Yes, some mistakes are subtle. But most are more along
the lines of "what idiot wrote this stupid code??? Oh,
wait, that was me. Oops. How could I have made such
a dumb mistake?"

Any number of things might lead the system to determine
that a process is attempting an invalid operation,
and that it needs to shut down the offending process.

Yes, and nearly ALL of those "number of things" are do to
human error on someone's part. Not necessarily the programmer,
but usually so. Face it: to err is human; but to really foul
things up requires a computer and someone who believes they're
an expert (but who is really just a pert). ;-)


--
Cheers,
Robbie Hatley
Tustin, CA, USA
lonewolfintj at pacbell dot net
(put "[usenet]" in subject to bypass spam filter)
http://home.pacbell.net/earnur/

 

[Default User]

:

That's like saying, "your car caught fire and burned up, Mr. Smith,
so we're sorry, but we can't pay on your claim; you're only insured
against actual CRASHES, not fires". In other words, it crashed.

A poor protest. Indeed, a fire is not a crash, which is why it's
normally covered under the comprehensive portion of your policy, not
the collision.

Likewise, a hang is not crash in computer programs. If you think they
are, then you're rather badly mistaken.




Brian

 

[Jakob Bieling]

Jakob Bieling wrote:

There's no requirement that the compiler abort, nor is there any
requirement for an "error". The only thing the Standard requires is a
diagnostic. The compiler could go ahead and finish compiling if the
designer wanted it to.

Oh, I did not know, thanks. Can you point me to the corresponding
paragraph in the Standard? 4.7 and 4.10 do not seem to cover this.

regards

 

[Default User]

Oh, I did not know, thanks. Can you point me to the corresponding
paragraph in the Standard? 4.7 and 4.10 do not seem to cover this.

Probably not. Which section mandates the compiler aborting?



Brian

 

[-]

C/C++ Programs can crash because of poor coding.
A question which I would like to ask is (to you)...

What OS are you using?