One out of five times opensips crash after cancelling an invite, always at free_contenttype -> free_params, with dbg msg "DBG:tm:clean_msg_clone: removing hdr->parsed 12".
what opensips revision are you using ?
Sorry for not being to clear, i use the 1.6.1-notls release running on debian etch and my client is a snom 190 if it is of any difference, I did some more debugging and noticed that crash only happens when the msg->multi is set when reaching clean_msg_clone, if i add check msg->multi && hdr->type == 12 and don't call clean_hdr_field if true then i don't see any crashes.
I think i found the problem, in my case nathelper and textops functions parses the body and sets msg->content_type->parsed which point outside the uas.request memory chunk as it always has, but in 1.6.1 someone has added HDR_CONTENTTYPE_T to hdr_allocs_parse and clean_msg_clone now tries to free this memory where param->next sometimes has an illegal pointer.
where do you call (for request) the nathelper and textops functions that triggers the parsing of content-type hdr? in request route? branch route? failure?
I'm trying to reproduce this to get to the bottom of it.
BTW, any chance to get access to the core file to inspect it?
I call nat_uac_test and has_body from request route.
Core output without optimization is attached if you want the full core dump please tell me where to upload i cant get it below 256k so it can be uploaded here.
Don't know if there is a reason to copy content_type->parsed in sip_msg_cloner but removing it solves this issue.
Patch to possible fix is uploaded, incl typo fix.
Does your request has params in the Content-Type hdr ?? Can you post the message causing the crash ?
No, only "Content-Type: application/sdp", i think there should be a content_type_cloner and possible also a content_length_cloner if these needs to be copied by sip_msg_cloner to be sure that they are not invalidated by another process which must be the case here, i don't have problems after removing the copy, header is just parsed again when i do has_body("application/sdp") in reply route.
Woow...looks like a backport error - the fix you made does exist on trunk...:(...Thanks a lot for finding and fixing this.!!
I made the necessary fixes in SVN.
Regarding the cloning - it will be more efficient to clone it, but it is a much more complex code and right now this was not the top most priority.
Thanks again and best regards,