Variable names are important

For the last two days I’ve been working on decoding video frames and displaying them. The idea is to run against the system clock which I’ve had working everytime so far. This time though, I decided to make a general decoder so that I didn’t have to worry about FFMpeg’s video decoded format which up until now has always been YUV420 which I just had a GL using SL shader convert on the fly. Everything gets converted to an RGBA bitmap so I don’t have to worry about it.

Anyway, variable names…

I buffer up the frames and then test them against the current system clock for a frame that’s ready to be presented. I had two variable names, frame and frame_temp which are pretty innocent. Unfortunately though, and which I kept missing whilst going through the code, I was grabbing a pointer in frame_temp and testing it. If it fell below the current system time then it would then be assigned to frame. If there was a previous frame then it would be cleared from the buffer queue and added to the unused buffer queue.

Now this is what I missed.

Frame_temp is first used, frame is unitialised (actually null), the tests are done on frame_temp and if failed then just exits with a null pointer. Fair enough.

It was a “typo”.

Hidden between four lines of code using frame_temp I had used the variable frame instead (which is null to start with). When I accessed a method on that class it would crash.

The error message was very obscure and nothing on google search or anywhere else was any help.

My mistake…

Most of the time I rely on debug log outputs. And whilst running this code, everything was running just as it should. It’s hard to follow multiple threads in debug output.

Finally, I ran it through gdb which took me straight to the line of code where it crashed. The line right after the “typo”.

Lesson learnt…

Leave a Reply

Your email address will not be published.