Can someone remind me how to tell gcc not to 0 initialise everything in debug mode

[awsdert]

Tried googling it but google didn't seem to understand what I was looking for, brought up everything but, I need to stop it happening so I can track down variables that need to be initialised

[john.c]

I am not aware that gcc zero-initializes everything in "debug mode". I assume you are talking about local variables since globals and statics are always zero-initialized if not explicitly initialized.

You could try looking here:
Debugging Options (Using the GNU Compiler Collection (GCC))

EDIT: I just tried the following:

#include <stdio.h>
 
void f()
{
    int a, b, c, d;
    if (a || b || c || d) printf("f: non-zero detected\n");
    else                  printf("f: all zeroes\n");
}
 
int main()
{
    int a, b, c, d;    
    if (a || b || c || d) printf("main: non-zero detected\n");
    else                  printf("main: all zeroes\n");
    return 0;
}

Output:
$ gcc zeroed.c -g
$ ./a.out
main: non-zero detected

[awsdert]

I am not aware that gcc zero-initializes everything in "debug mode". I assume you are talking about local variables since globals and statics are always zero-initialized if not explicitly initialized.

You could try looking here:
Debugging Options (Using the GNU Compiler Collection (GCC))

EDIT: I just tried the following:

#include <stdio.h>
 
void f()
{
    int a, b, c, d;
    if (a || b || c || d) printf("f: non-zero detected\n");
    else                  printf("f: all zeroes\n");
}
 
int main()
{
    int a, b, c, d;    
    if (a || b || c || d) printf("main: non-zero detected\n");
    else                  printf("main: all zeroes\n");
    return 0;
}

Output:
$ gcc zeroed.c -g
$ ./a.out
main: non-zero detected

I appreciate the link but I already looked there, that's what I meant by everything but what I was looking for, and yeah that non-zero situation is definitly what I'm looking for in debug mode yet when I run the code in release vs debug I never get the bug showing in debug (which is obviously annoying, how am I to catch a segfault that only happens in release mode, there won't be enough information for me to identify what function/code to look through). True the uninitialised data I'm looking for is usually 0'd even in release mode but occasionally I get a crash and I can only attribute it to uninitialised data, if only I knew where to look I could fix it.

[rstanley]

Tried googling it but google didn't seem to understand what I was looking for, brought up everything but, I need to stop it happening so I can track down variables that need to be initialized

If you are referring to global variables, then "-fno-zero-initialized-in-bss" may be what you are looking for. See this page for more information.

Local variables are never initialized to zero by default.

Also, please view a complete list of gcc options.

[awsdert]

If you are referring to global variables, then "-fno-zero-initialized-in-bss" may be what you are looking for. See this page for more information.

Local variables are never initialized to zero by default.

Also, please view a complete list of gcc options.

I don't think it's global variables that are the issue but I might as well try. Thanks for the link though, might prove more helpful than google in this case.

[rstanley]

I don't think it's global variables that are the issue but I might as well try. Thanks for the link though, might prove more helpful than google in this case.

After having a good strong cup of coffee this morning, I can't understand why you would want any and all variables NOT initialized to zero or some legitimate value! I can't see how variables picking up garbage values left in memory, would in any way help to debug any program!

True the uninitialised data I'm looking for is usually 0'd even in release mode but occasionally I get a crash and I can only attribute it to uninitialised data, if only I knew where to look I could fix it.

Seems simple. Go through your code and locate any local variables not initialized, and initialize them to zero or some legitimate value, and all pointers to NULL. As for malloc(), use memset(), or switch to calloc(). As for realloc() you would need to memset() the added memory. If that does not fix the problem, then you have more serious problems.

Also, as soon as you free() and allocated memory, ALWAYS set the pointer to NULL, to avoid accidentally read or write the memory freed! I list all this not just to you but for the benefit of all readers of this thread.

[ghoul]

As for realloc() you would need to memset() the added memory.

While this is possible, it might turn out more complicated than other cases which are simple enough.

My guess is that one would have to keep track of the size of the currently allocated memory chunk then do something like:

memset(ptr + previous_size, 0, current_size - previous_size);

[rstanley]

While this is possible, it might turn out more complicated than other cases which are simple enough.

My guess is that one would have to keep track of the size of the currently allocated memory chunk then do something like:

memset(ptr + previous_size, 0, current_size - previous_size);

Why do you think that was NOT what I was referring to??? I didn't think I had to give an explicit example to the OP!

[awsdert]

After having a good strong cup of coffee this morning, I can't understand why you would want any and all variables NOT initialized to zero or some legitimate value! I can't see how variables picking up garbage values left in memory, would in any way help to debug any program!


Seems simple. Go through your code and locate any local variables not initialized, and initialize them to zero or some legitimate value, and all pointers to NULL. As for malloc(), use memset(), or switch to calloc(). As for realloc() you would need to memset() the added memory. If that does not fix the problem, then you have more serious problems.

Also, as soon as you free() and allocated memory, ALWAYS set the pointer to NULL, to avoid accidentally read or write the memory freed! I list all this not just to you but for the benefit of all readers of this thread.

There ARE legitimate reasons to avoid initialising all variables, namely speed, that initialisation takes an instruction, if your function can potentially exit before the variable is needed then that's wasted time which can add up, I make a point of avoiding initialising variables until I actually need them, yes it means the occasional bug creeps in when I forget it's not initialised but it's not often that happens.

[rstanley]

There ARE legitimate reasons to avoid initialising all variables, namely speed, that initialisation takes an instruction, if your function can potentially exit before the variable is needed then that's wasted time which can add up, I make a point of avoiding initialising variables until I actually need them, yes it means the occasional bug creeps in when I forget it's not initialised but it's not often that happens.

When you say, "initialization", do you mean at compile time with a constant, or "assignment" later.

int main(void)
{
   int a;         // Not initialized, assigned later
   int b = 0;     // Initialization to 0 at compile time
   ... 
   a = 0;         // Initial assignment, or re-assignment later

   return 0;
}

Depending on the context, the compiler might optimize the code by converting the "assignment", to an "initialization". Bottom line, actual 'Initialization" has no overhead at run-time. Look at the assembler code.

[hamster_nz]

Try running with valgrind.

This brings back up what I was typing in a different thread:

I pity the next person who comes along, and should the debugger stops at "ENUM( Type, E_BUFF_TYPE_INDICE, GL_ELEMENT_ARRAY_BUFFER );" is left scratching their head. Only to find out that "GfxBufTypeEnums[]" has been declared too small.

However, it more than likely that the debugger won't stop, and your code will just trash a random memory location somewhere, giving them an almost unsolvable bug that will haunt their nightmares.

In this case, that next person is might be you.

[awsdert]

Try running with valgrind.

This brings back up what I was typing in a different thread:



In this case, that next person is might be you.

Well that's not possible, the enums have counts built into them, I use those counts when declaring the array size so the compiler is able to catch it before it can reach production stage

[Salem]

>There ARE legitimate reasons to avoid initialising all variables, namely speed, that initialisation takes an instruction
Yet here you are, scrambling to figure out where you screwed up.

The imaginary microsecond you saved has turned into very real days of wtf is wrong with my code.

Your first order of business is to make the damn thing work by the most reliable means possible.
One of those things is rigorous initialisation of variables.

When it works, then you profile and optimise.

> yes it means the occasional bug creeps in when I forget it's not initialised but it's not often that happens.
ROFLMAO

How many times do you plan falling down the same hole, wondering how to get yourself out of it, before you realise a better way might be to avoid falling down the hole in the first place?

[awsdert]

>There ARE legitimate reasons to avoid initialising all variables, namely speed, that initialisation takes an instruction
Yet here you are, scrambling to figure out where you screwed up.

The imaginary microsecond you saved has turned into very real days of wtf is wrong with my code.

Your first order of business is to make the damn thing work by the most reliable means possible.
One of those things is rigorous initialisation of variables.

When it works, then you profile and optimise.

> yes it means the occasional bug creeps in when I forget it's not initialised but it's not often that happens.
ROFLMAO

How many times do you plan falling down the same hole, wondering how to get yourself out of it, before you realise a better way might be to avoid falling down the hole in the first place?

Say what you will, I don't mind the time lost, I have an eternity in heaven to look forward to, this life is just a pastime until God declares it time to take me.

[hamster_nz]

Say what you will, I don't mind the time lost, I have an eternity in heaven to look forward to, this life is just a pastime until God declares it time to take me.

Since you bring god into it:

There is an old joke, about a person who dies in a flood, after telling all their potential rescuers that "Gold will provide".

In heaven they ask "God, why did you forsake me, and leave me to die"?

And God says "What! I sent you a car, a truck, a boat and a helicopter, what more could I do?".

Your project works in "debug mode" (by this I assume you mean with no optimizations), but not in "release mode" (optimizations turned on). If that is the case it is far more likely that the optimizer are making use of an assumption you made in your code.

Does it compile cleanly with ALL compiler warnings tuned on?

You can still debug with optimizations turned on - it can just be a little more confusing, as the code is all jumbled up.

If you can point me to how I can recreate this bug with minimal effort on my part (e.g. not much more than "git clone ..." and then type "make mybug") I can take a look at it.