src/g23m-gsm/sms/sms_for.c: bogus malloc removed The new error handling code that was not present in TCS211 blob version contains a malloc call that is bogus for 3 reasons: 1) The memory allocation in question is not needed in the first place; 2) libc malloc is used instead of one of the firmware's proper ways; 3) The memory allocation is made inside a function and then never freed, i.e., a memory leak. This bug was caught in gcc-built FreeCalypso fw projects (Citrine and Selenite) because our gcc environment does not allow any use of libc malloc (any reference to malloc produces a link failure), but this code from TCS3.2 is wrong even for Magnetite: if this code path is executed repeatedly over a long time, the many small allocations made by this malloc call without a subsequent free will eventually exhaust the malloc heap provided by the TMS470 environment, malloc will start returning NULL, and the bogus code will treat it as an error. Because the memory allocation in question is not needed at all, the fix entails simply removing it.

T_STEP meas_rep_bs_pa_mfrms_2();
T_STEP meas_rep_bs_pa_mfrms_3();
T_STEP meas_rep_bs_pa_mfrms_4();
T_STEP meas_rep_bs_pa_mfrms_5();
T_STEP meas_rep_bs_pa_mfrms_6();
T_STEP meas_rep_bs_pa_mfrms_8();
T_STEP wait_ncsync_idle_2_14(int count);
T_STEP wait_ncsync_idle_2_31(int count);
T_STEP wait_ncsync_idle_3_33(int count);
T_STEP wait_ncsync_dedicated(int count);
T_STEP wait_ncsync_dedicated_1020A(int count);
T_STEP wait_ncsync_dedicated_102(int count);
T_STEP wait_ncsync_dedicated_102a(int count);
T_STEP wait_ncsync_dedicated_102b(int count);
T_STEP wait_ncsync_dedicated_102c(int count);
T_STEP sync_to_ncell_14_fails_once();
T_STEP ncell_bcch_read_fails_for_ncell_14();
T_STEP ncell_reporting_multiband_0_scell_is_gsm900();
T_STEP ncell_reporting_multiband_0_scell_is_gsm1800();
T_STEP ncell_sync_ncc_permitted_check();
T_STEP ncell_reporting_multiband_1_scell_is_gsm900();
T_STEP ncell_reporting_multiband_1_scell_is_gsm900_4ch();