I installed a Linux(Ubuntu12.04LTS), how can I test RuntimeE

[MewCatcher]

I want to see the message when causing a runtime error on my own computer, can gcc or a way to run program can achieve this goal?

If the way permits windows system, that will also be welcomed!

Thanks!!!

[lbv]

I want to see the message when causing a runtime error on my own computer, can gcc or a way to run program can achieve this goal?

If the way permits windows system, that will also be welcomed!

If you just want to reproduce a Runtime Error (segmentation fault, crash, etc.), you just need a critical test case for which your program produces a fatal error. Of course, this depends on the problem you're trying to solve, and your code. However, just reproducing the crash is generally not very interesting, because it only tells you it broke, but it doesn't tell you why (knowing which test case produced the crash is still useful, though).

The next step would be using a debugger. It can tell you the exact point in your program where it broke, and you can explore and change on-the-fly the state of your program at that point. I use gcc/g++ as my compilers and gdb as the debugger, and it's served me well, and they do work in Linux and Windows. There's a lot of information about them on the web as well, so it shouldn't be too hard to learn the basics of it.

[MewCatcher]

Thanks for your suggestion!
But I have tried this code, causing no RE. Why?

Code: Select all

int main( )
{
    int *n = new int [ 3 ];
    printf( "First test.\n" );
    printf( "%d\n", n[ 10 ] ); /* Does this  */
    printf( "Last test.\n" );
    return 0;
}

In Ubuntu, I run program by "./re"( compiling by "gcc re.c -o re" ), and the output is:

Code: Select all

First test.
Last test.

The middle sentence seems ignored.? What's the reason? How to run or compile the program is correct?
Thanks again!~

[lbv]

Thanks for your suggestion!
But I have tried this code, causing no RE. Why? (..)

In general, an invalid memory access has unpredictable results. Many things could happen. Your program could crash (in many different ways), it may not crash and produce crazy results, it may not crash and produce results that seem okay... who knows.

I find two strange things about the code you have posted, one is that you didn't use any include directives, where you should at least have used cstdio or stdio.h. Another is that you used gcc instead of g++ to compile a program that seems to be written in C++ (because of the new operator). I wonder how you managed to get that compiled... although I'm not familiar with Ubuntu and their setup may allow such strange things.

After a few minor changes, when I compile your code in my laptop, it prints:

Code: Select all

First test.
0
Last test.

It's probably not crashing because, although n[10] is not a valid position in the segment of memory you reserved with new, it probably doesn't go outside of the block of memory assigned to your program, so C/C++ simply keeps going. The tacit assumption, if you could call it that, made by the language is that you know what you're doing, and doesn't stop you from doing it. It's only when you play with things that are clearly outside of your sandbox, that the OS comes and says "hey! you can't do that".

For example, try this:

Code: Select all

        printf( "First test.\n" );
        printf( "%d\n", n[ 1 << 20 ] ); /* Does this  */
        printf( "Last test.\n" );

Since it tries to access a memory location much farther away from the block of memory of your variable, it's more likely to trigger the response you wanted.

[MewCatcher]

Oh, I just didn't post the "#include <stdio.h>". When compiling, the code includes them.
Oh, again... I didn't switch to Ubuntu system when posting the reply, so the code file in "ext4" partion cannot be read in Windows ( NTFS partion ), thus I just... you know, too careless... while you are extremely careful.

Accessing a larger address really causes a crash, thank you very much! I got it, and I must be more careful...