PocketMatrix

No ideas?

The good news is I think I found the problem on the device, and it doesn't look like an iterator problem as I had expected. So I won't need remote debugging to find the problem.

The bad news is that the problem is quite weird. I'm still looking at the code wondering how it could possibly do what it is doing. (And seemingly only on the device.) So maybe remote debugging will be necessary.

Help is appreciated.

My actual crash is complicated. :-(

It's either a compiler error or a very subtle coding bug. It's one of those problems where adding print statements around the code makes the problem go away, and I'm just setting a couple of values in an array. Everything seems to be in range, and if I remove the print statements it fails, otherwise it's OK. (Oh, and it works fine on the PC.)

The data is initialized. It is a vector of vector of int which is initialized to 4x8 all -1.

Rows 2 and 3 are supposed to always be -1, and they are before a few lines of code in a switch statement are executed. After the switch, a value becomes changed in those lines. The lines in the switch for that case are hardcoded to only touch rows 0 and 1. The other index (0 to 7) is not hardcoded but it is within range. There is a break in each case.

The data is only really touched there. So because my app is single threaded, and it is fine before the lines and not fine after, we know the problem is in those lines. And yet, visually checking the lines reveals no way it could cause the problem.

It happens only on release builds on the device. If I produce a build hardcoded to only take a particular path through the switch statement, one build for each case, they all work fine. If I add a print statement at the end of the case, it works fine.

This leads me to believe that the optimizer is doing something wacky when optimizing the switching statement. I will try other things such as changing it to an if-else statement.

In my experience, optimizer bugs are like this. I had a lot on the DEC Alpha compiler, eventually we had to just disable the optimizer as it was too flaky.

OK if I change the switch statement to an if-else-if statement the optimization problem remains. If I change it to just if statements (no elses) the problem disappears.

The value being switched on is constant and mutually exclusive, so only one case is ever done, even in the multiple if statements.

How about posting the code so we can take a look at it?

Isn't there a #pragma to disable optimizations selectivly?