I am working on an android app that uses some native code. I had it working and then I made a few updates and ran my tests. The app froze every time I called a native function and the internal linking of data stops.
I managed to isolate the cause down to a single line, but the line should not have that effect.
std::vector<float> OrderedPointCloud;
//std::vector<float> testeatetaetart; //Problem
std::vector<float> Pose;
This works fine.
std::vector<float> OrderedPointCloud;
std::vector<float> testeatetaetart; //Problem
std::vector<float> Pose;
This freezes and messes up the linking.
I have no idea what this declaration does to make the app fail. I have tried renaming it, changing the type, making fields of different types and adding more fields. Nothing effects the result.
There is no limit to how many fields you can have in a class in C++ and the ordering and position of fields does not matter. I see no conflicting naming errors and the field is not being used. Unless there are some limitations or quirks on android I see no possible problem that could stem from this.
I have no idea what causes this, I get no errors and I have no idea where to look for more info. Any help would be greatly appreciated.
This is called "undefined behavior".
A bug somewhere in your C++ code results in a corrupted heap or stack. Program execution doesn't always immediately fail, in this situation. Often it carries on for some indeterminate amount of time, because the code doesn't immediately attempt to use the portion of memory that got overwritten or corrupted. But, at some point later, when the code does attempt to dereference a pointer, or something along these lines, in the corrupted area of memory, things then quickly come apart at that point.
I can, for example, write a trivial main() that, as the first order of business proceeds and blows away the stack by running past the end of a locally-declared array. My main() will happily proceed and do a bunch of other things, make calculations, print some messages, and it will eventually crash when main() returns. Except the bug is not at the point where main() returns, but much, much earlier.
This is most likely is the case with you. In your case, the effects of the bug would only be seen when statically-scoped objects get declared in some specific order, that result in important statically-scoped objects getting overwritten at some point as a result of the bug, resulting in a locked up program. And when the statically-scoped objects get declared in a different order, the corrupted bits would be the ones that the code already used, and no longer needed, hence the impact of the bug is not seen.
You will need to learn how to use whatever debugging or static analysis tools are available to you in order to isolate, and locate the actual bug in your code. The real answer to your question is something that only you can figure out and nobody else, since it is only you who has access to your actual code, your entire code, and can examine it.
Welcome to C++.