Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

The ways for an application to crash

rageshctechrageshctech Member Posts: 20
Hi all,

I'm going to create an application that emulates different types of crashes...
So, can you guys help me by [b]listing all known ways in which an application can crash?[/b]
For example,
The code:
[code]char *p = 0; // Null pointer.
char x = 0;
*p = x;
[/code]
Is an illegal write, which shows the error:
[img=http://img384.imageshack.us/img384/2627/errorkh2.jpg]
and the application will be closed...
Please help!!!

Comments

  • JonathanJonathan Member Posts: 2,914
    Hi,

    Some other fun ways might include stack overflow (write an infinitely recursive function), consuming all available memory (infinite loop that mallocs), dereferencing a pointer that's uninitialized and copying over the return address on the stack. You can probably trigger an NX failure by trying to use an address you've malloc'd as a function pointer too, if your CPU supports it... :-)

    Yes, I have done all of these by accident at some point. ;-)

    Jonathan
    ###
    for(74,117,115,116){$::a.=chr};(($_.='qwertyui')&&
    (tr/yuiqwert/her anot/))for($::b);for($::c){$_.=$^X;
    /(p.{2}l)/;$_=$1}$::b=~/(..)$/;print("$::a$::b $::c hack$1.");
  • LundinLundin Member Posts: 3,711
    There are almost as many ways as there are functions available to the programmer... Every program bug has the potential to cause a crash.

    - Accessing uninitalized memory / wrong addresses. Null pointers, array bugs, pointer bugs etc.
    - Jumping to wrong addresses / using invalid function pointers.
    - Out of memory. Stack / global RAM / heap / program memory / HD memory...
    - I/O errors. File handling, pipes/IPC, hardware I/O, registry I/O etc etc.
    - Accessing corrupt hardware.
    - Divide by zero.
    - Deadlock bugs. Waiting for resources that are never released. Could be both hardware and software resources.
    - Semaphore/mutex bugs. Multi-threaded programs that don't protect shared variables.
    - Crashing the OS through wrong use of API functions.
    - Doing dumb things in assembler, such as not stacking CPU registers before using them.
    - And on and on and on...
  • rageshctechrageshctech Member Posts: 20
    Thank you very much for listing those...
Sign In or Register to comment.