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.