Is There Any Way a C/C++ Program Can Crash Before Main()

I have an c++ code which crashes on startup before reaching execution of main() where might the issue reside?

There are several things that take place before the actual execution starts. The first thing that comes to my mind is initialization of global variables. For example:

#include <cstdlib>

int getSomeValue(){
    // some code to produce crash, e.g. as suggested by Barmar...
    abort();
    return 0;
}

int value = getSomeValue();

int main(){
    return 0;
}

And concerning your question of how to find such a bug, the answer is: use a debugger.

What is the easiest way to make a C++ program crash?

The abort() function is probably your best bet. It's part of the C standard library, and is defined as "causing abnormal program termination" (e.g, a fatal error or crash).

my program just crash after for loop ?any solution for that?

In ajouter_en_tete*(), when you allocate nouveau, malloc() does not initialise any field, so suivante might not be NULL unless you explicitly set it.

More specifically, you check if (ll->premier == NULL), and:

• set ll->premier = nouveau in both cases (move that out of the if block).
• Only update nouveau->suivante in the second case, so it's never set to NULL. Might as well move that out of the if block too, so it will always be set (and in the case of NULL, it's set to NULL as it should be.

I'll show what I mean.

1 nouveau = (cellule *) malloc(sizeof(cellule));
2 nouveau->p = pp;
3 nouveau->suivant = ll->premier;
4 ll->premier = nouveau;

After line 1 and 2, nouveau->suivant is probably not NULL. If the list is empty, ll->premier is NULL, so in line 3 nouveau->suivant also gets set to NULL. In line 4 ll->premier is set to nouveau.

Next time through, same as before nouveau->suivant is not NULL at line 2, at line 3 nouveau->suivant is set to ll->premier which was the node allocated last time, and ll->premier is set to nouveau. The node from last time is unchanged, at this point ll->premier->suivant is the previous node, ll->premier->suivant->suivant is still NULL.

In all cases, it works this way.

What Can Cause a C Program to Crash Operating System

On modern systems with hardware-enforced privilege separation between user-mode and kernel-mode, and an operating system that functions to correctly configure these mechanisms, you simply cannot crash the system from a user mode process.

Any of those errors are trapped by the CPU, which call exception handlers in the OS which will quickly pull the plug on your system.

If I had to guess, a piece of hardware is overheating or malfunctioning:

• Overheating CPU due to poor thermal conductivity with heatsink
• Failing / under-sized power supply
• Failing DIMMs
• Failing hard drive
• Failing CPU
• Failing / overheating GPU

I've seen cryptocoin-mining software bring a system to its knees because it was pushing the limits of the GPU. When the card would lock-up/reset, the driver would get confused or lock-up, and the system would end up needed rebooted.

Your system is doing next to nothing when you're just sitting there browsing the web, etc. But if your system locks up when you start running a CPU-intensive application, it can bring out problems that you didn't know where there.

While this is a little out-of-place on Stack Overflow, it falls into one of those grey areas between hardware and software. I would stress-test your system, keeping an eye on CPU/GPU/memory temperatures, and power supply voltages. Check out MemTest86, Stresslinux.

A C program to crash the system

It's easy to write a program that invokes undefined or implementation-defined behavior. Some of those programs could potentially crash the system.

But by definition, this is inconsistent. And modern OSes take pains (though not 100% successfully) to prevent a rogue app from crashing the system.

---

Related Topics