(gdb) bt
#0 0x7765d625 in raise () from /lib64/libc.so.6
#1 0x7765ee05 in abort () from /lib64/libc.so.6
#2 0x7328f7a2 in shm_free (faked_req=, t=) at ../../evi/../mem/shm_mem.h:403
#3 free_faked_req (faked_req=, t=)
at t_msgbuilder.h:260
#4 0x73290b8f in run_f
In sip_msg_cloner() if updatable=0 reply_lump is placed inside the same chunk
as new_msg,
if updatable>0 reply_lump is allocated.
But later in free_faked_req() code does not distinguish how reply_lump has been
set up.
We hit into call shm_free(faked_req->reply_lump) with faked_req->reply_lump
po
Hello,
Can you privately send me the script you are using and describe how you are
able to reproduce this ? ( email at vladp...@opensips.org if possible )
Best Regards,
Vlad
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/484#issuecomment-97877
@AVFedorov , any chances to grab your script for reproducing this crash ?
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/484#issuecomment-98725125___
Devel mailing list
Devel@lists.opensips.org
http://l
I send all to Vlad.
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/484#issuecomment-98785862___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Hello,
The shm_free checks whether the pointer is inside the SHM memory, and in your
case it is entirely out of the memory block, so it looks like a memory
corruption. Furthermore, sip_msg_cloner is called with updatable=0 only for
replies, but in your case the crash is related to a request.
T
I add some debug to t_msgbuilder.h:free_faked_req
inline static void free_faked_req(struct sip_msg *faked_req, struct cell *t)
{
LM_DBG("free_faked_req 1 faked_req->req_lump=%p,
t->uas.request->reply_lump=%p\n",faked_req->reply_lump,t->uas.request->reply_lump);
if (faked_req->new_
I am also seeing this problem in a certain scenario, the output from opensips
in logs is:
Jun 30 15:54:52 lab-pett-opensips2 scp1a[13568]: CRITICAL:tm:free_faked_req:
>>> pkg_free() on shm ptr 0x7fd12f2aeb30 - aborting!
It seems you have hit a programming bug.
---
Reply to this email directly o
Managed to get a core dump for this:
Core was generated by `/usr/local/opensips/sbin/opensips -P
/var/run/opensips/opensips.pid -m 64 -M 64'.
Program terminated with signal SIGABRT, Aborted.
#0 0x7f86d7b2a107 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56
Hello,
Thanks for the backtrace, Pete. Will coordinate with you today to login on the
box where the crash occurs and further debug the core file.
Best Regards,
Vlad
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/484#issuecomment-117547723_
Some further info @vladpaiu - this seems very connected to failure route. If
there is a failure route defined (even one that does only a simple xlog) then
opensips will crash on failure response.
I feel sure it must be related to script somehow too as I have other 2.1
scripts which exhibit no c
Hi @AVFedorov , @petekelly - I'm taking over this issue.
If any of you could describe how to reproduce this crash (like what kind of
call needs to be canceled, etc), it will be great to sort it out asap.
Thanks and regards,
Bogdan
---
Reply to this email directly or view it on GitHub:
https://g
Closed #484 via f01fe377c48a79bbba9032f10c9a94605b7c3913.
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/484#event-385348824___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-
@AVFedorov and @petekelly many thanks for the information and support you
provided in regards to this bug.
It was tricky to reproduce and fix as this crash was trigger only if PATH
support was used and requests were looked up with PATH header.
This fix will be part of the tomorrow minor release
14 matches
Mail list logo
