Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

C++: Strange behavior: Return value changes on the return statement

I'm facing a very very strange behavior my application.

I'm going to describe my situation and then explain what is going wrong.

Situation

I have a method with a signature like this:

const StructureDef *getStructure(const std::string &theme, int index);

And I call it in this piece of code:

const StructureDef *sDef = 0;
do 
{
    sDef = ss->getStructure(theme, rand() % ss->availableStructureCount());
} while (!sDef);

I'm using this do-while structure, because the return value of the getStructure method might be NULL, depending on the combination of theme and index. So basically, what it does is asking random structures until we get a valid one. (If you want to know the detail, take a look at the screenshots.)

The method iterates over a std::vector<StructureDef> using it's ::iterator. And for each StructureDef, it checks if the structure belongs to that theme. If so, post-increase the counter and check if it is equal to the requested index. Like this:

// inside the loop
if (i++ == index)

When this if succeeds, the current StructureDef * is returned:

return sDef;

What is going wrong

I'm using XCode 4.4 it's debugger to see step by step what is going on, which is basically gdb.

The method I explained first, find a StructureDef * that matches my needs. So it returns that pointer. Here is a screenshot of the moment just before it is going to return in the debugger:

Return point in the debugger

(The line after the for-loop is simply return 0;)

Here the pointer sDef * points to 0x1d563270, which is where the correct instance of the StructureDef is located.

Next screenshot is what we get in the piece of code where I called that method:

Caller gets wrong address

As you can see, the pointer sDef *, which got the return value of the method, now points to 0x2fe03804. This is not what the method returned at all! I'm thinking that this is pointer points to somewhere on the stack, instead of the heap. (It should be the heap since the std::vector class stores its objects on the heap, right?).

I can't use Valgrind yet, since I'm on Mac OS X 10.8, which isn't supported by Valgrind.

I'm totally surprised by this behavior. I can't see why this is happening... Can it be that my compiler is broken, or is it doing some strange "optimization"?

Thanks in advance!
Martijn


To clarify DeadMG's comment:

I'm using different themes:

iron
wood
ice

etc...

My identifiers look like this:

iron__downside_touch_and_go
iron__platform__700_65
iron__wall_bang
wood__platform__600_40

etc... What I want to do is pick the structure with a specific index within one theme. So not the index the set of structures of all themes together, but the index of the subset of one theme. Take a look at the piece of code again :)


Update!!!

I gave wrong info. The vector is of the type std::vector<StructureDef>!! It stores objects. Not pointers!

So what (I think) I'm doing with the .operator->() call is the same as: &(*it). And it looks like it is working. To me it looked a bit stupid to write & and * after each other.


@Ben Voigt:

Architecture: enter image description here

Optimisation: enter image description here

like image 750
Martijn Courteaux Avatar asked Jul 10 '12 13:07

Martijn Courteaux


1 Answers

It looked like the debugger I was using (LLDB and not GDB as I though first) did not display the memory values correctly. After switching to GDB, the debugger showed the memory addresses I excepted to see. When I added a print statement like this:

printf("StructureDef* pointer = %llx\n", (unsigned long long int)(void*) sDef);

it looks like GDB is right. For testing purposes, I switched back to LLDB, and magically it was working correctly as well.

Maybe, I'm dealing with what this guy wrote: https://stackoverflow.com/a/9709462/155137

I hope it is a bug in the LLDB debugger. Because, otherwise, I think there is something really broken on my installation.

like image 79
Martijn Courteaux Avatar answered Oct 21 '22 05:10

Martijn Courteaux