I’m writing to spread some knowledge about a memory initialization problem in the QMI SDK 03.00.02 related to the ciipcchanfixedinfo array and the CIMAXIPCCHAN macro. When compiling for and running slqssdk on an ARM9 32-bit target, I saw the following in /var/log/syslog:
In running slqssdk through gdb, I was able to eventually discover that the ciinit() routine was clobbering the dlgcb struct used in dlregister(), corrupting the dlgcbp->dlpidcount member.
ciinit() attempts to initialize the cigcb struct. It is a simple loop that associates the cigcb.ciipcchanlist.cichanfixedinfop member with a constant data set stored in the ciipcchanfixedinfo array.
The loop iterates based on the return value of cigetnumchannels(), which in turn uses the sizeof(array)/sizeof(array.element) compiler trick to “dynamically” calculate the number of elements in the ciipcchanfixedinfo array at compile time.
The cigcb.ciipcchanlist array member is statically initialized at compile time using the CIMAXIPCCHANNELS macro.
There is a mismatch in the number of elements defined in the “dynamic” array ciipcchanfixedinfo and the “static” array cigcb.ciipchanlist. This results in writing past the end of cigcb.ciipcchanlist and into the dlgcb memory region, resulting in the corruption mentioned earlier.
I cannot get this problem to reproduce on an x86 system, but have noticed odd behaviors on an amd64 system unless the gcc -m32 flag is used. It may be coincident or related. However, it is reliably reproducible on the ARM9 system. I think that this problem would affect all platforms, however.
Simply updating CIMAXIPCCHANNELS to match the number of elements in ciipcchanfixedinfo is one part of the solution. A second part would be to add CIMAXIPCCHANNELS to the array initializer for ciipcchanfixedinfo so that any discrepancies in the future would immediately show up at compile time:
I hope that this helps someone else in the future.