-
Couldn't load subscription status.
- Fork 172
Open
Description
I have observed the following issue in re:
- Send a SIP message and store a reference to it.
- Note:
conn_sendallocates astruct sip_connwithnrefs=1(from the allocation, zero refs from adding it toht_conn). Then thestruct sip_msgstores another reference sonrefs=2.
- Note:
- Dereference the sip struct (
sip_close). - Block main thread for a couple of seconds until remote party closes the socket cleanly.
- This can occur when debug logging is enabled with a slow logging callback.
- In the meantime, the remote party closes the socket,
tcp_close_handlerdereferences the connection (nownrefs=1) andsip_closeflushesht_connwhich dereferences it again (nownrefs=0and the connection is freed).
- Dereference the SIP message
- but
struct sip_connhas already been freed.
Result: SIGABRT after:
mem: mem_deref: magic check failed 0xb5b5b5b5 (0x120d5c0)
Reason: the connection struct has been dereferenced once by tcp_close_handler and once too many by sip_close flushing sip->ht_conn.
I can fix this by removing the call to mem_deref from tcp_close_handler in transp.c. But, is that a good change? Could it cause memory leaks?
P.S. this issue is actually occurring in a custom fork of an older version of re. I don't know for sure that it affects the latest re, but the relevant code looks the same.
Metadata
Metadata
Assignees
Labels
No labels