0

I'm having a weird problem trying to get my release build working in Xcode 4.2 using llvm. I've turned off all optimisation settings for the release scheme, and as far as I can tell the release build matches all the settings of the debug build. Regardless of this, the following problem occurs when working with some structures from Box2D, a physics library - but I am unsure if the problem has anything todo specifically with that.

b2CircleShape* circleShape = new b2CircleShape();

circleShape->m_p.Set(0,0);
circleShape->m_radius = m_radius;

b2FixtureDef fixture;
fixture.shape = circleShape;
fixture.density = m_density;

m_fixtureDefs.push_back(fixture); // std::vector

b2FixtureDef fix2 = fixture;
b2FixtureDef fix3 = m_fixtureDefs[0] // EXC_BAD_ACCESS

When I remove all instances of access to m_fixtures, no problems occur. When I run in the development scheme no errors occur. I am really, really confused, if someone could point me in the right direction for errors to look for it would be much appreciated

EDIT:

More interesting stuff

for (vector<b2FixtureDef>::iterator i = m_fixtureDefs.begin() ; i != m_fixtureDefs.end(); ++i)
{

}

This appears to loop forever, making me very confused. It seems like the structure m_fixturesDef has some kind of problem, but I have no idea why whatever weird corruption is going on is only occurring in this particular variable.

Tomas
  • 1,379
  • 1
  • 13
  • 20
  • It looks like a memory error, so it will be hard to debug. You should try running it with valgrind. Also, could it be that `circleShape` gets deleted before `m_fixtureDefs`? – juanchopanza Apr 19 '12 at 05:45
  • I'll try that now. No, the first extract is 'as is' in the code. – Tomas Apr 19 '12 at 05:55
  • Check default constructor b2FixtureDef::b2FixtureDef() and copy constructors b2FixtureDef::b2FixtureDef(const b2FixtureDef&) b2FixtureDef::operator=(const b2FixtureDef&). Use debug print to see variable values and program flow. – alexander Apr 19 '12 at 06:23
  • The constructor just sets shape as NULL, and there is no overided copy constructor – Tomas Apr 19 '12 at 06:31
  • Do you use memcpy, memset or something like that? Can you confirm reported problems if you compile example shown above like a standalone program? – alexander Apr 19 '12 at 07:32
  • No I don't. The example above as a standalone program runs just fine. I feel like I should also mention that the settings on my release build match my development build, but the development build still crashes. – Tomas Apr 21 '12 at 07:31
  • Oh, and when all those sections are avoided, other parts of the codebase start to get weird errors – Tomas Apr 21 '12 at 07:32
  • It looks like problem is in another place of your program. There are a lot of reasons for such errors, for example see http://www.yolinux.com/TUTORIALS/C++MemoryCorruptionAndMemoryLeaks.html or http://scottmcpeak.com/memory-errors/. Valgrind is really good tool to debug errors like that. Loki Astari's recommendations is really good too. If you you can show whole code, I can take a look at it and tell something else. – alexander Apr 21 '12 at 14:31
  • I ended up enabling a bunch of pedantic flags fixing some seemingly trivial warnings and now the program runs as expected. I'm very confused, but I guess thats programming. Thats a very good link though alexander, thanks – Tomas Apr 22 '12 at 01:15

1 Answers1

2

By default POD objects are not initializes in C++ so their initial value (unless explicitly initialized) are inherently random.

When you build in debug mode the compiler usually inserts extra initialization code to zero out values. Thus you can easily see different behaviors between debug and release builds.

A quick way to find this kind of problem is to check your compiler warnings; see if you are using a variable before it has been initialization (you may need to turn on the warnings) or something similar.

Note: You can fix a lot of serious problems by making sure your code compiles with zero warnings with the warning level as high as reasonable (usually a step above default). (a warning is really a logical error in your code).

Martin York
  • 257,169
  • 86
  • 333
  • 562
  • I don't have any compiler warnings, and the project runs through clang as well. Any tips for finding the problem? – Tomas Apr 19 '12 at 06:16
  • @TomasCokis: Did you turn on all the warnings? My absolute minimum is `-ansi -pedantic -Wall -Werror` Though I usually have a few others: `-ansi -pedantic -Wall -Werror -Wextra -Wstrict-aliasing -Wunreachable-code -Wshadow -Weffc++` The XCode coompiler has the same flags turn them on see what happens. – Martin York Apr 19 '12 at 15:59
  • I turned on a bunch of warnings, fixed some end of file things and some other non trivial stuff, messed around with project settings for an hour, reverted the project file and all of a sudden the thing runs again. I'm not quite sure what was the issue, but I'm going to accept this because the warnings seemed to lead me to fixing the issue – Tomas Apr 22 '12 at 01:16