FreeCalypso > hg > fc-magnetite
view cdg3/sap/tra.pdf @ 516:1ed9de6c90bd
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.
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sun, 22 Jul 2018 06:04:49 +0000 |
parents | c15047b3d00d |
children |
line wrap: on
line source
;******************************************************************************** ;*** File : tra.pdf ;*** Creation : Wed Mar 11 09:58:53 CST 2009 ;*** XSLT Processor : Apache Software Foundation / http://xml.apache.org/xalan-j / supports XSLT-Ver: 1 ;*** Copyright : (c) Texas Instruments AG, Berlin Germany 2002 ;******************************************************************************** ;*** Document Type : Service Access Point Specification ;*** Document Name : tra ;*** Document No. : 8411.106.98.101 ;*** Document Date : 2002-06-10 ;*** Document Status: BEING_PROCESSED ;*** Document Author: TVO ;******************************************************************************** PRAGMA SRC_FILE_TIME "Thu Nov 29 09:55:46 2007" PRAGMA LAST_MODIFIED "2002-06-10" PRAGMA ID_AND_VERSION "8411.106.98.101" VALTAB VAL_entity_name VAL 6 TRA_ENTITY_NAME_LEN "Max name length" VALTAB VAL_ack_flg VAL 0 TRA_ACK "acknowledged" VAL 1 TRA_NAK "not acknowledged" VALTAB VAL_dti_direction VAL 0 TRA_DTI_NORMAL "DTI used normally" VAL 1 TRA_DTI_INVERTED "DTI is inverted" VALTAB VAL_dti_conn VAL 0 TRA_CONNECT_DTI "Connect DTI to TRA" VAL 1 TRA_DISCONNECT_DTI "Connect DTI to upper layer" VAR entity_name "name of an neighbour entity" B VAL @p_tra - VAL_entity_name@ VAR ack_flg "acknowledge flag" B VAL @p_tra - VAL_ack_flg@ VAR link_id "link identifier" L VAR dti_direction "DTI direction" B VAL @p_tra - VAL_dti_direction@ VAR dti_conn "DTI connect" B VAL @p_tra - VAL_dti_conn@ ; TRA_ACTIVATE_REQ 0x80000019 ; TRA_ACTIVATE_CNF 0x80004019 ; TRA_DEACTIVATE_REQ 0x80010019 ; TRA_DEACTIVATE_CNF 0x80014019 ; TRA_DTI_REQ 0x80020019 ; TRA_DTI_CNF 0x80024019 ; TRA_DTI_IND 0x80034019 PRIM TRA_ACTIVATE_REQ 0x80000019 { } PRIM TRA_ACTIVATE_CNF 0x80004019 { ack_flg ; acknowledge flag } PRIM TRA_DEACTIVATE_REQ 0x80010019 { } PRIM TRA_DEACTIVATE_CNF 0x80014019 { } PRIM TRA_DTI_REQ 0x80020019 { dti_conn ; DTI connect link_id ; Link identifier of DTI entity_name [TRA_ENTITY_NAME_LEN] ; Communication entity name dti_direction ; DTI direction } PRIM TRA_DTI_CNF 0x80024019 { dti_conn ; DTI connect link_id ; Link identifier } PRIM TRA_DTI_IND 0x80034019 { link_id ; link identifier }