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.
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).
Related
Consider this mock-up of my situation.
in an external header:
class ThirdPartyObject
{
...
}
my code: (spread among a few headers and source files)
class ThirdPartyObjectWrapper
{
private:
ThirdPartyObject myObject;
}
class Owner
{
public:
Owner() {}
void initialize();
private:
ThirdPartyObjectWrapper myWrappedObject;
};
void Owner::initialize()
{
//not weird:
//ThirdPartyObjectWrapper testWrappedObject;
//weird:
//ThirdPartyObject testObject;
}
ThirdPartyObject is, naturally, an object defined by a third party (static precompiled) library I'm using. ThirdPartyObjectWrapper is a convenience class that eliminates a lot of boiler-plating for working with ThirdPartyObject. Owner::initialize() is called shortly after an instance of Owner is created.
Notice the two lines I have labeled as "weird" and "not weird" in Owner::initialize(). All I'm doing here is creating a couple of objects on the stack with their default constructors. I don't do anything with those objects and they get destroyed when they leave scope. There are no build or linker errors involved, I can uncomment either or both lines and the code will build.
However, if I uncomment "weird" then I get a segmentation fault, and (here's why I say it's weird) it's in a completely unrelated location. Not in the constructor of testObject, like you might expect, but in the constructor of Owner::myObjectWrapper::myObject. The weird line never even gets called, but somehow its presence or absence consistently changes the behavior of an unrelated function in a static library.
And consider that if I only uncomment "not weird" then it runs fine, executing the ThirdPartyObject constructor twice with no problems.
I've been working with C++ for a year so it's not really a surprise to me that something like this would be able happen, but I've about reached the limit of my ability to figure out how this gotcha is happening. I need the input of people with significantly more C++ experience than me.
What are some possibilities that could cause this to happen? What might be going on here?
Also, note, I'm not asking for advice on how to get rid of the segfault. Segfaults I understand, I suspect it's a simple race condition. What I don't understand is the behavior gotcha so that's the only thing I'm trying to get answers for.
My best lead is that it has to do with headers and macros. The third party library actually already has a couple of gotchas having to do with its headers and macros, for example the code won't build if you put your #include's in the wrong order. I'm not changing any #include's so strictly this still wouldn't make sense, but perhaps the compiler is optimizing includes based on the presence of a symbol here? (it would be the only mention of ThirdPartyObject in the file)
It also occurs to me that because I am using Qt, it could be that the Meta-Object Compiler (which generates supplementary code between compilations) might be involved in this. Very unlikely, as Qt has no knowledge of the third party library where the segfault is happening and this is not actually relevant to the functionality of the MOC (since at no point ThirdPartyObject is being passed as an argument), but it's worth investigating at least.
Related questions have suggested that it could be a relatively small buffer overflow or race condition that gets tripped up by compiler optimizations. Continuing to investigate but all leads are welcome.
Typical culprits:
Some build products are stale and not binary-compatible.
You have a memory bug that has corrupted the state of your process, and are seeing a manifestation of that in a completely unrelated location.
Fixing #1 is trivial: delete the build folder and build again. If you're not building in a shadow build folder, you've set yourself up for failure, hopefully you now know enough to stop :)
Fixing #2 is not trivial. View manual memory management and possible buffer overflows with suspicion. Use modern C++ programming techniques to leverage the compiler to help you out: store things by value, use containers, use smart pointers, and use iterators and range-for instead of pointers. Don't use C-style arrays. Abhor C-style APIs of the (Type * array, int count) kind - they don't belong in C++.
What fun. I've boiled this down to the bottom.
//#include <otherthirdpartyheader.h>
#include <thirdpartyobject.h>
int main(...)
{
ThirdPartyObject test;
return 0;
}
This code runs. If I uncomment the first include, delete all build artifacts, and build again, then it breaks. There's obviously a header/macro component, and probably some kind of compiler-optimization component. But, get this, according to the library documentation it should give me a segfault every time because I haven't been doing a required initialization step. So the fact that it runs at all indicates unexpected behavior.
I'm chalking this up to library-specific issues rather than broad spectrum C++ issues. I'll be contacting the vendor going forward from here, but thanks everyone for the help.
I have a pretty weird 'crash' at a customer's computer. Using logs I was able to track it to this line of code:
myvar = 1; //This 'crashes'. myvar is declared as 'double'
The code is obviously okay. But myvar is a member variable of a class. And there is a global instance of this variable and line of code is in the constructor. So it's executed before main(). Not good style, I know...
My questions:
- Is it allowed to use float/double before main()?
- Is there some kind of "InitFloatSystem()" function that I could call?
Some more info:
- It's a Win32 / C++
- There's no crash message, the program just closes
- try/catch doesn't help
I'm really out of ideas...
Finally, finally found the problem. It's an issue of Visual Studio 2012. I found at the Microsoft website, even though they reported different side effects: http://connect.microsoft.com/VisualStudio/feedback/details/771122/floating-point-math-change-from-vs2008-to-vs2012-affects-native-code-but-not-managed-code
My guess is that the compiler now uses by default processor features that aren't available on some old processors. Using this compiler option magically fixed it:
/arch:IA32
Unless your binary is corrupted there is no way a simple assignment should be causing a crash - unless you've overloaded the assignment operator?
What's more than likely is that you've corrupted the heap, or invoked undefined behaviour some where and what you've tracked down is just a side effect of this.
Application Verifier is quite handy on windows for helping track down these sorts of things:
http://msdn.microsoft.com/en-us/library/ms220948(v=vs.90).aspx
But.. its by no means simple to track down the real cause of these sorts of bugs, highest warning levels, warnings as errors and static code checkers help to keep majority of these issues at bay.
I have a project I'm working on. I recently switched it to release mode with full optimization just to get an idea how some things will perform out of debug mode. On doing so however, I noticed that there were a few irregularities. In my particular case, I have a sprite who's alpha value is different (more transparent) in release mode then debug mode.
To check my findings, I made a copy of the release mode build options, but turned off optimizations (being sure that DEBUG and other related preprocessor options were removed) and it performed correctly. Something in the optimization process modifies the behaviour of my system. It's probably because there are variables I'm not initializing in my classes somewhere.
My question is, is there an alternative, aside from manually combing over my code, to making sure things are initialized properly? I've checked the warnings that pop up, but all are related to int to float/float to int conversion and possible loss of data and enum qualifiers, and none of them are related to the alpha on my sprite.
I'm using Visual Studio 2010 if it makes a difference.
This type of thing can be very difficult to debug. I suggest that you replace the optimization one-by-one, until you find the one that causes the anomly. You can then narrow the issue further by applying that optimization to each translation unit (file) one-by-one.
Another way to deal with this issue is essentially a data trace. Analyze code to determine what item of data is controling your alpha. Locate each statement that writes to the data. Put breakpoint or traces on those statements. Then determine the first point in the executable where the release data differs from the debug data.
Turn on as many warnings as you can to catch uninitialized variables. Run the code through a static LINT tool, like cppcheck. It's been a while since I've used VS, but I'm pretty sure you can set up your debugger to break on accessing uninitialized variable accesses and trace it from there.
If the code is multithreaded, then you likely have a race condition, or the compiler may be reordering things that wouldn't ordinarily make a difference if threads didn't interact, so if that's the case, double-check your proper use of locks.
Use an always-initialized template for all your member variables.
template<typename T> class always_initialized {
T t;
public:
operator T&() { return t; }
operator const T&() const { return t; }
always_initialized() : t(T()) {}
template<typename K> always_initialized(K&& ref) : t(std::forward<K>(ref)) {}
};
I am occasionally getting odd behavior from boost::lower, when called on a std::wstring. In particular, I have seen the following assertion fail in a release build (but not in a debug build):
Assertion failed: !is_singular(), file C:\boost_1_40_0\boost/range/iterator_range.hpp, line 281
I have also seen what appear to be memory errors after calling boost::to_lower in contexts such as:
void test(const wchar_t* word) {
std::wstring buf(word);
boost::to_lower(buf);
...
}
Replacing the calls boost::tolower(wstr) with std::transform(wstr.begin(), wstr.end(), wstr.begin(), towlower) appears to fix the problem; but I'd like to know what's going wrong.
My best guess is that perhaps the problem has something to do with changing the case of unicode characters -- perhaps the encoding size of the downcased character is different from the encoding size of the source character?
Does anyone have any ideas what might be going on here? It might help if I knew what "is_singular()" means in the context of boost, but after doing a few google searches I wasn't able to find any documentation for it.
Relevant software versions: Boost 1.40.0; MS Visual Studio 2008.
After further debugging, I figured out what was going on.
The cause of my trouble was that one project in the solution was not defining NDEBUG (despite being in release mode), while all the other modules were. Boost allocates some extra fields in its data structures, which it uses to store debug information (such as whether a data structure has been initialized). If module A has debugging turned off, then it will create data structures that don't contain those fields. Then when module B, which has debugging turned on, gets its hands on that data structure, it will try to check those fields (which were not allocated), resulting in random memory errors.
Defining NDEBUG in all projects in the solution fixed the problem.
An iterator range should only be singular if it's been constructed with the default constructor (stores singular iterators, i.e doesn't represent a range). As it's rather hard to believe that the boost's to_lower function manages to create a singular range, it suggests that the problem might also be elsewhere (a result of some undefined behavior, such as using uninitialized variables which might be initialized to some known value in debug builds).
Read more on Heisenbugs.
General Question which may be of interest to others:
I ran into a, what I believe, C++-compiler optimization (Visual Studio 2005) problem with a switch statement. What I'd want to know is if there is any way to satisfy my curiosity and find out what the compiler is trying to but failing to do. Is there any log I can spend some time (probably too much time) deciphering?
My specific problem for those curious enough to continue reading - I'd like to hear your thoughts on why I get problems in this specific case.
I've got a tiny program with about 500 lines of code containing a switch statement. Some of its cases contain some assignment of pointers.
double *ptx, *pty, *ptz;
double **ppt = new double*[3];
//some code initializing etc ptx, pty and ptz
ppt[0]=ptx;
ppt[1]=pty; //<----- this statement causes problems
ppt[2]=ptz;
The middle statement seems to hang the compiler. The compilation never ends. OK, I didn't wait for longer than it took to walk down the hall, talk to some people, get a cup of coffee and return to my desk, but this is a tiny program which usually compiles in less than a second. Remove a single line (the one indicated in the code above) and the problem goes away, as it also does when removing the optimization (on the whole program or using #pragma on the function).
Why does this middle line cause a problem? The compilers optimizer doesn't like pty.
There is no difference in the vectors ptx, pty, and ptz in the program. Everything I do to pty I do to ptx and ptz. I tried swapping their positions in ppt, but pty was still the line causing a problem.
I'm asking about this because I'm curious about what is happening. The code is rewritten and is working fine.
Edit:
Almost two weeks later, I check out the closest version to the code I described above and I can't edit it back to make it crash. This is really annoying, embarrassing and irritating. I'll give it another try, but if I don't get it breaking anytime soon I guess this part of the question is obsolete and I'll remove it. Really sorry for taking your time.
If you need to make this code compilable without changing it too much consider using memcpy where you assign a value to ppt[1]. This should at least compile fine.
However, you problem seems more like another part of the source code causes this behaviour.
What you can also try is to put this stuff:
ppt[0]=ptx;
ppt[1]=pty; //<----- this statement causes problems
ppt[2]=ptz;
in another function.
This should also help compiler a bit to avoid the path it is taking to compile your code.
Did you try renaming pty to something else (i.e. pt_y)? I encountered a couple of times (i.e. with a variable "rect2") the problem that some names seem to be "reserved".
It sounds like a compiler bug. Have you tried re-ordering the lines? e.g.,
ppt[1]=pty;
ppt[0]=ptx;
ppt[2]=ptz;
Also what happens if you juggle about the values that are assigned (which will introduce bugs in your code, but may indicator whether its the pointer or the array that's the issue), e.g.:
ppt[0] = pty;
ppt[1] = ptz;
ppt[2] = ptx;
(or similar).
It's probably due to your declaration of ptx, pty and ptz with them being optimised out to use the same address. Then this action is causing your compiler problems later in your code.
Try
static double *ptx;
static double *pty;
static double *ptz;