Object leaving scope causes program crash

[JohnDev]

I am working on a proprietary iOS app written mainly in c++. There is an object Foo that causes the program to crash whenever it leaves scope. I have an older version of the code that works, so I was able to get some information from that. The code is exactly the same for the Foo object and the files using the Foo object in both versions.

For example this would cause a crash in the new version when the if statement reached its end,
if(true){
Foo temp(int, string, string, int);
}

When debugging the older version, when Foo leaves scope the destructor is called and there is a line in the assembly code,
"Foo::~Foo at Foo.h at line 13"
However in the newer version, when Foo leaves scope the same line is instead,
"Foo::~Foo()"

After this line is reached, the program crashes without exception. I have tried declaring a destructor for the Foo object, but when I do I get a linker error claiming that it's a duplicate symbol. I have searched through all relevant files and have not found any definition of a destructor. Foo does not inherit from any other object either.

Does anyone have any ideas on what could cause something like this?

[gunnerfunner]

if(true){
Foo temp(int, string, string, int);
} 

this looks like a function declaration inside the if(true) {} condition?
If temp returns Foo then it should instead be:

auto fooVar = temp(int, string, string, int)

but in this case fooVar is scoped to strictly within the if() statement and cant be used beyond it unless its copied/moved while the program control is still within the loop

[JohnDev]

The "Foo temp(int, ....);" was just an example of what the constructor looks like for a Foo object. I realize the "int" and "string" might have made it ambiguous. The actual code looks more like this.

 Foo temp(anIntVariable, aStringVariable, aStringVariable2, anIntVariable2);

The if statement doesn't exist in the code, but if I inserted it to test the destruction of Foo's at the end of the scope. So the if statement just creates a new Foo object, then it gets destroyed. But the destruction causes a crash.

The Foo object's header is something like this

class Foo{
   private:
      int anInt;
      string someString;
      string anotherString;
      int aSecondInt;
   public:
      Foo(int anInt, string someString, string anotherString, int aSecondInt);
      getInt1();
      getSomeString();
      getAnotherString();
      getSecondInt();
}

[gunnerfunner]

The actual code looks more like this.
 
Foo temp(anIntVariable, aStringVariable, aStringVariable2, anIntVariable2);

it still looks like a function declaration to me …

[JohnDev]

That is a creation of a Foo object on the stack, this way the destructor is called automatically at the end of the scope.

Creating an object like Foo temp = *new Foo(....); would be creating it dynamically which would mean I would have to call delete() on temp. It makes no difference here. Either way the program will crash when the Foo object is destroyed.

[gunnerfunner]

you are not reading the posts carefully, no object is being created in your code snippet, it's just a function declaration. To create (temporary, in this case perhaps) objects the function has to be called with appropriate arguments

[ne555]

> I have searched through all relevant files and have not found any definition
> of a destructor.
look better.
the debugger should pinpoint the file and line number (as long as you are compiling with debug info)
the linker kicked you with duplicate symbol, should have mentioned the translation units where it was.
you gave us nothing to work on.


> Does anyone have any ideas on what could cause something like this?
bad memory management or corruption because out of bounds access.
run your code through valgrind and may find it.

[JohnDev]

I think you are not understanding the code. It is not a function declaration. There is a Foo constructor explicitly defined, as shown above, and that is what is being used to construct the object. An object is being constructed. However, that is still missing the point all together. It does not matter how the object is created, anyway it is created still leads to a crash when using the destructor.

[Thomas1965]

Foo temp(anIntVariable, aStringVariable, aStringVariable2, anIntVariable2);
It can be both a function declaration and an object created on the stack.

https://stackoverflow.com/questions/2275653/object-construction-forward-function-declaration-ambiguity

Try to use the object initialization list.
Foo temp{anIntVariable, aStringVariable, aStringVariable2, anIntVariable2};

[mbozzi]

JohnDev wrote:

I get a linker error claiming that it's a duplicate symbol

If you are certain that there is no other destructor for Foo in the code, verify that you aren't linking an old object file where another is defined. (Try a clean build).

[ne555]

if you do not have a destructor the debugger may be complaining at the one provided by the compiler.
the crash happens when one of its members is destroyed, probably because of corrupted memory.

[MikeyBoy]

Thomas1965 wrote:

Foo temp(anIntVariable, aStringVariable, aStringVariable2, anIntVariable2);
It can be both a function declaration and an object created on the stack.

Huh? If it were a function declaration, the parameter types would be specified, e.g.

Foo temp(int anIntVariable, std::string aStringVariable, std::string aStringVariable2, int anIntVariable2);

The code you quoted is unambiguously instantiating a Foo object.

[gunnerfunner]

we're at/near abouts the territory of C++'s most-vexing-parse:
https://stackoverflow.com/questions/1424510/most-vexing-parse-why-doesnt-a-a-work

[JohnDev]

Thanks for all the ideas. I was able to track down an object file in one of the libraries being used that contained a Foo.o file. I dumped this file and saw it was already defining a Foo destructor. This must have been causing the conflict in destruction. I changed my Foo object to another name like FooX and now my object is working as intended.

[MikeyBoy]

we're at/near abouts the territory of C++'s most-vexing-parse:
https://stackoverflow.com/questions/1424510/most-vexing-parse-why-doesnt-a-a-work

Yes, but that only applies to default constructors/functions with no arguments.

When the constructor has arguments, the syntax is unambiguous, because a function declaration states the types of the parameters, and an object instantiation doesn't.

[Thomas1965]

Yes, you are right. Just didn't read it careful enough.

[MikeyBoy]

No problem, if I had a penny for every time I misread some code... I wouldn't need to read code any more :)