Opened 12 years ago

Last modified 12 years ago

#1671 closed defect

Unfreed transmit buffer (pjsip_tx_data) upon stack shutdown/restart — at Initial Version

Reported by: nanang Owned by: bennylp
Priority: normal Milestone: release-2.2
Component: pjsip Version: trunk
Keywords: Cc:
Backport to 1.x milestone: Backported: no

Description

On stack shutdown/restart, some pending operations on a transmit buffer may be forced to break/stop the operation without notifying the application and cause the transmit buffer dangling unfreed. As the transmit buffer may hold OS resources (e.g: atomic counter, mutex, memory), this will introduce OS resource leak issue (especially on resource with 'OS handle' such as mutex, note that memory will automatically be freed by PJLIB memory pool framework on stack shutdown).

After investigation, here are possible async operations involving transmit buffer:

  • DNS resolve.
  • Transport send:
    • for TCP/TLS, it may actually a connect pending, this should be safe already, as on_data_sent() callback is invoked during transport destruction,
    • the async send operation itself.

Note that even usually there is timeout timer on every async operation, normally the timer poll is stopped during shutdown stage, so we can rely on it.

Alternative solution:

  • Introduce new behaviour: always invoke callback on DNS/transport destruction for any pending operation. This is considered to be risky as it potentially introduces more issues :)
  • Maintain a list of pending transmit buffers, so SIP endpoint can free any 'dangling' transmit buffers when the SIP endpoint is destroyed.

Change History (0)

Note: See TracTickets for help on using tickets.