Passing pointer: different value in stack?

Question

I do:

typedef struct {
    Scene *scene;
    MeshStore *store;
    float angle;
} DebugModel

...
free_entire_store(debug_model.store);

/* Frees the store and any meshes related to it */
void free_entire_store(MeshStore *store) {
   /* implementation not important for the problem at hand */
}

Now, if I gdb this putting a breakpoint at the beginning of free_entire_store I get the following strange data..

(gdb) p debug_model  
$5 = {scene = 0x1044a680, store = 0x1044a630, angle = 87.8401108}  
(gdb) p store  
$6 = (MeshStore *) 0x10438b40

debug_model is a global, the above debugging output is from the same point int he program.

So, even though I simply pass the pointer as a parameter, it somehow gets changed. The stack is corrupted, albeit in a very predictable manner (the same data appears every run). What could have caused this? I don't think I freed anythign twice or something before calling this function. How can the value passed as parameter not correspond with the value in the stack?

Without some context, it's impossible to say. Try cutting your code down to the minimum required to still exhibit the problem. — Oliver Charlesworth, Jan 19 '11 at 21:10
I'm wondering if stack corruption could cause this. All I can tell from gdb is that the value int he stack is not the value I passed as a parameter. Will Valgrind tell me more than that? — buddhabrot, Jan 19 '11 at 21:12
Are you really asking for the values of `debug_model` and `store` like that, or are you changing stack levels? Is `debug_model` a global? Normally, those variables would not coexist in the same scope. Either you've got an odd design, or there's things you aren't telling us. Either way, we are going to have a hard time helping you. — David Thornley, Jan 19 '11 at 21:18
the code displayed here does not cause the problem. Valgrind is amazingly useful in finding problems on the heap. If it finds nothing then also try enabling stack protection in gcc see http://stackoverflow.com/questions/1629685/when-and-how-to-use-gccs-stack-protection-feature — gravitron, Jan 19 '11 at 21:20
`libefence` has been indispensable for me when trying to find bugs that trash the heap. Also, a static code analyzer such as the free `cppcheck` might find the issue without having to compile anything. — SiegeX, Jan 20 '11 at 00:40
debug_model is a global. I'll try valgrind and some more experiments, got no idea what is happening. — buddhabrot, Jan 20 '11 at 07:53

Argote · Answer 1 · 2011-01-21T00:30:15.357

0

I think it's because you are making a copy of the pointer in the function so it can be modified locally. Both should point to the same thing.

If you want to use the exact same pointer inside the function and outside, you should pass a pointer to a pointer.

typedef struct {
    Scene *scene;
    MeshStore *store;
    float angle;
} DebugModel

...
free_entire_store(&(debug_model.store));

/* Frees the store and any meshes related to it */
void free_entire_store(MeshStore **store) {
    MeshStore *originalStore = *store;
    /* implementation not important for the problem at hand */
}

edited Jan 21 '11 at 00:30

answered Jan 20 '11 at 08:50

Argote

2,155
1
15
20

Already tried this, same result (the double pointer was also different in stack than it was for &(debug_model.store)). There is no reason why the pointer value would have changed? – buddhabrot Jan 20 '11 at 09:56
I think the pointer to the pointer would be different, but if you make a local variable like this: `MeshStore* originalStore = *store;` inside your `free_entire_store` method, then its value should be the same as `debug_model.store` – Argote Jan 21 '11 at 00:27

score 0 · Accepted Answer · answered Jan 20 '11 at 09:50

0

Are you sure you placed the breakpoint correctly? store might not yet be assigned, especially if you compiled with optimisations. Try breaking after the first line of the method to be sure it is assigned already.

answered Jan 20 '11 at 09:50

Benoit Thiery

6,325
4
22
28

Ok, I compiled turning off all optimizations and it allowed me to find the error, the optimization caused the strange 'corrupted stack" symptom, which disappeared when compiling with -O0. – buddhabrot Jan 20 '11 at 12:26
1

You really can't debug debug optimized C code with gdb , gdb gets all confused. – nos Jan 20 '11 at 18:32

Passing pointer: different value in stack?

2 Answers2