Hi Daniel,
This patch needs to be applied to avoid core.
Thanks
Jijo
On Wed, Sep 19, 2012 at 10:54 AM, Jijo <realjijo(a)gmail.com> wrote:
>
> Hi All,
>
> Finally i found the issue,
>
> Here is one of the bad trace for SUBSCRIBE(722bytes) and NOTIFY(1282bytes)
> which corrupted the memory. The messages came in the order NOTIFY and
> SUBSCRIBE. The core is generated in a different place but I believe this
> could be the reason for memory corruption.
>
> Here is the trace UDP Process 27294 processing NOTIFY and Process 27303 processing
> SUBSCRIBE .
>
>
>
> The explanation and implementation is below
>
>
>
> 2012-09-19T02:06:17+01:00 [info] sipserver: [27303] INFO: <script>:
> CI=1-3292(a)10.233.20.152 -R39 - Entry R-URI=1234 FD=10.233.20.152
> SI=10.233.20.152
>
> 2012-09-19T02:06:17+01:00 [info] sipserver: [27294] INFO: <script>:
> CI=1-3292(a)10.233.20.152 -R1 - Force LAN socket: tcp:10.233.20.151:5060<null>
>
> 2012-09-19T02:06:17+01:00 [info] sipserver: [27303] INFO: <script>:
> CI=1-3292(a)10.233.20.152 -R1 - Force LAN socket: tcp:10.233.20.151:5060<null>
>
> 2012-09-19T02:06:17+01:00 [err] sipserver: [27303] ERROR: <core>
> [tcp_main.c:2357]: tcp_conn_send_put : calling wbufq_add
>
> 2012-09-19T02:06:17+01:00 [err] sipserver: [27303] ERROR: <core>
> [tcp_main.c:730]: ERROR: wbufq_add(722 bytes): buf:SUBSCRIBE
> sip:1234@10.233.20.141:5063;transport=tcp SIP/2.0
>
> Record-Route: <sip:10.233.20.151;tran
>
> 2012-09-19T02:06:17+01:00 [err] sipserver: [27303] ERROR: <core>
> [tcp_main.c:747]: ERROR: wbufq_add(722 bytes): first:b00519f4 last:b00519f4
>
> 2012-09-19T02:06:17+01:00 [err] sipserver: [27303] ERROR: <core>
> [tcp_main.c:774]: ERROR: wbufq_add(2 last free crt_size:722):
> first:b00519f4 last:b00519f4
>
> 2012-09-19T02:06:17+01:00 [err] sipserver: [27294] ERROR: <core>
> [tcp_main.c:796]: ERROR: wbufq_insert(1282 bytes): buf:NOTIFY
> sip:1234@10.233.20.141:5063;transport=tcp SIP/2.0
>
> Record-Route: <sip:10.233.20.151;transpo
>
> 2012-09-19T02:06:17+01:00 [err] sipserver: [27294] ERROR: <core>
> [tcp_main.c:801]: ERROR: wbufq_insert(2 last free ): first:b00519f4
> last:b00519f4
>
> 2012-09-19T02:06:17+01:00 [err] sipserver: [27294] ERROR: <core>
> [tcp_main.c:820]: ERROR: wbufq_insert(22 last free ): first:b00519f4
> last:b00519f4
>
> 2012-09-19T02:06:17+01:00 [err] sipserver: [27359] ERROR: <core>
> [tcp_main.c:887]: ERROR: wbufq_run(3 last free ): first:b00519f4
> last:b00519f4
>
> 2012-09-19T02:06:17+01:00 [crit] sipserver: [27359] : <core>
> [mem/q_malloc.c:157]: BUG: qm_*: fragm. 0xb00519dc (address 0xb00519f4) end
> overwritten(0, 0)!
>
> 2012-09-19T02:06:18+01:00 [alert] sipserver: [27265] ALERT: <core>
> [main.c:755]: child process 27359 exited by a signal 11
>
> 2012-09-19T02:06:18+01:00 [alert] sipserver: [27265] ALERT: <core>
> [main.c:758]: core was generated
>
> 2012-09-19T02:06:18+01:00 [info] sipserver: [27265] INFO: <core>
> [main.c:770]: INFO: terminating due to SIGCHLD
>
>
>
> Process 27294(NOTIFY) created the TCP connection structure for destination
> IP and just before calling wbufq_insert(), context switch happened and
> process 27303(SUBSCRIBE) got the cpu. Since the connection structure is
> already available process 27303 add the SUBSCRIBE message(722 bytes) to
> wbufq. Afterwards process 27294 got the CPU and invoked wbufq_insert()
> which basically corrupted the memory due to an overflow with the existing
> implementation.
>
>
>
>
>
> inline static int _wbufq_insert(struct tcp_connection* c, const char*
> data,
>
>
> unsigned int size)
>
> {
>
> struct tcp_wbuffer_queue* q;
>
> struct tcp_wbuffer* wb;
>
>
>
> q=&c->wbuf_q;
>
> if (likely(q->first==0)) /* if empty, use wbufq_add */
>
> return _wbufq_add(c, data, size);
>
> :
>
> :
>
> :
>
> :
>
> if ((q->first==q->last) &&
> ((q->last->b_size-q->last_used)>=size)){
>
> /* one block with enough space in it for
> size bytes */
>
>
>
> memmove(q->first->buf+size,
> q->first->buf, size);
>
> memcpy(q->first->buf, data, size);
>
> q->last_used+=size;
>
> }
>
>
>
> The above condition shall be true in this case and memmove was moving the
> pointer which was causing the overflow.
>
> memmove(void *dest, const void *src, size_t n);
>
>
>
> As per the memmove man page, the src shall be copied with size ‘n’ to a
> temporary buffer and then temporary buffer to dest.
>
>
>
> dest is q->first->buf+size: which is basically (q->first->buf + NOTIFY
> MSG SIZE). so the dst will move my 1282 bytes, so we have remaining space
> of only 818 bytes.
>
>
>
> src is q->first->buf: which is basically copied to temp buffer with NOTIFY
> SIZE(1282bytes).
>
>
>
> Finally we are moving the buffer from temporary buffer of size 1282 bytes
> to buffer which we left with 818 bytes, This basically corrupt the memory
> and on wbufq_run we see the memory corruption
>
>
>
> 2012-09-19T02:06:17+01:00 [crit] sipserver: [27359] : <core>
> [mem/q_malloc.c:157]: BUG: qm_*: fragm. 0xb00519dc (address 0xb00519f4) end
> overwritten(0, 0)!
>
>
>
> I think we don’t need memove, so we can change the code as below
>
>
>
> if ((q->first==q->last) && ((q->last->b_size-q->last_used)>=size)){
>
> /* one block with enough space in it for size bytes */
>
> //memmove(q->first->buf+size, q->first->buf, size);
>
> memcpy(q->first->buf+q->last_used, data, size);
>
> q->last_used+=size;
>
> }
>
> OR
> we need only the else part as it always add the block to the first.
>
> Thanks
> Jijo
>
> On Wed, Jul 18, 2012 at 12:42 PM, Daniel-Constantin Mierla <
> miconda(a)gmail.com> wrote:
>
>> Hello,
>>
>> sorry, I just read the last messages in the thread and I didn't noticed
>> it is about a crash, but thought it is about an annoying log message.
>>
>> The backtrace is no longer matching the latest sources of the 3.1 branch,
>> but I expect it is due to a double free issue, so you have to update to
>> latest 3.1.6, as suggested by other users here. There were many fixes from
>> 3.1.0 to 3.1.6.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 7/17/12 6:03 PM, Jijo wrote:
>>
>> Hi,
>>
>> This is not happening at shutdown or status check. Its aborting when
>> the system is active.
>>
>> Thanks
>> Jijo
>> On Tue, Jul 17, 2012 at 3:06 AM, Daniel-Constantin Mierla <
>> miconda(a)gmail.com> wrote:
>>
>>> Hello,
>>>
>>> does it keep being or it is one time and that's it?
>>>
>>> That is printed at shut down or if pkg_status() or shm_status() is
>>> executed from some part of code or in config via cfgutils module functions.
>>>
>>> You can get rid of them by setting memdbg and memlog to a value higher
>>> than debug global parameter.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 7/16/12 5:28 PM, Jijo wrote:
>>>
>>> Thanks.. It is not easy to upgrade as it is happening at customer
>>> system.
>>> Is there any change occurred for this issue.I looked at it, but didn't
>>> see anything in q_malloc.c/qm_status()
>>>
>>>
>>> On Mon, Jul 16, 2012 at 11:12 AM, Jon Bonilla <manwe(a)aholab.ehu.es>wrote:
>>>
>>>> El Mon, 16 Jul 2012 10:27:42 -0400
>>>> Jijo <realjijo(a)gmail.com> escribió:
>>>>
>>>> > Hi All,
>>>> >
>>>> > I'm observing a core intermittently at "qm_status (qm=0x786cd000) at
>>>> > mem/q_malloc.c:763" for kamailio version 3.1.0
>>>> >
>>>>
>>>> I'd say that you're using a very old version. You should update your
>>>> branch to
>>>> 3.1.6 or upgrade to a newer branch.
>>>>
>>>>
>>>> _______________________________________________
>>>> sr-dev mailing list
>>>> sr-dev(a)lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> sr-dev mailing listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>
>>>
>>> --
>>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>>
>>>
>>
>> --
>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>
>>
>
Hello,
when looking at the database structure description I noticed, that the
htable module key_value has a max length of 128 characters.
I need more characters for caching lua scripts - are there any concerns
about increasing the max length in some tables to 1024 characters (or
even more?) using MySQL TEXT field type?
kind regards
jasmin
Hello,
the db_mysql module seems to read the [client] section in my.cnf only if
a [group] in the db-url is specified.
(at least this is valid for the default-character-set option).
In my opinion this does not make sense, because the mysql reference
manual says:
"The [client] option group is read by all client programs"
http://dev.mysql.com/doc/refman/5.1/en/option-files.html
Are there any reasons for the current situation or can this be
considered as a bug?
Kind Regards
Jasmin
Hello,
I have a few questions about the websocket module which I have successfully
installed but I wasn't able to make calls through it:
1. After setting up the proxy ip:port in the call.htm file (of sipml5) to *
127.0.0.1:5060* the client started to work but kamailio script refused to
establish my connection because the following condition was not satisfied:
*if ($Rp != MY_WS_PORT && $Rp != MY_WSS_PORT) {*
* xlog("L_WARN", "HTTP request received on $Rp\n");*
* xhttp_reply("403", "Forbidden", "", "");*
* exit;*
*}*
*MY_WS_PORT* and *MY_WSS_PORT *are set to 80 and 443 respectively, as the
default config example of websocket module says so.
Then, I decided to change the ip:port to *127.0.0.1:80*, always in the
call.htm file and afterwards the condition was satisfied but sipml5 dies
with
SIP stack start: proxy='127.0.0.1:80', realm='<sip:127.0.0.1>',
impi='2000', impu='<sip:2000@127.0.0.1>'
tsk_utils.js:97<http://127.0.0.1/sipml5/src/tinySAK/src/tsk_utils.js?svn=5>
Connecting to 'ws://127.0.0.1:80'
tsk_utils.js:97<http://127.0.0.1/sipml5/src/tinySAK/src/tsk_utils.js?svn=5>
Stack starting
tsk_utils.js:97<http://127.0.0.1/sipml5/src/tinySAK/src/tsk_utils.js?svn=5>
Unexpected response code: 200 :1 <http://127.0.0.1/>
__tsip_transport_ws_onerror
tsk_utils.js:97<http://127.0.0.1/sipml5/src/tinySAK/src/tsk_utils.js?svn=5>
__tsip_transport_ws_onclose
tsk_utils.js:97<http://127.0.0.1/sipml5/src/tinySAK/src/tsk_utils.js?svn=5>
Failed to connet to the server
Finally, I ended up commenting the condition block and restored the
original values of ip:port to *127.0.0.1:5060* .
Having done that, I tried again and another error was thrown but this time,
in the next condition block: * if ($hdr(Host) == $null ||
!is_myself($hdr(Host))) *
<script>: WebSocket
Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: DEBUG: <script>: Host:
127.0.0.1:5060
Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: DEBUG: <script>:
Origin: http://127.0.0.1
Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: DEBUG: <core>
[socket_info.c:589]: grep_sock_info - checking if host==us: 14==9 && [
127.0.0.1:5060] == [127.0.0.1]
Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: DEBUG: <core>
[socket_info.c:589]: grep_sock_info - checking if host==us: 14==9 && [
127.0.0.1:5060] == [127.0.0.2]
Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: DEBUG: <core>
[socket_info.c:589]: grep_sock_info - checking if host==us: 14==13 && [
127.0.0.1:5060] == [192.168.10.95]
Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: DEBUG: <core>
[socket_info.c:589]: grep_sock_info - checking if host==us: 14==13 && [
127.0.0.1:5060] == [192.168.10.55]
Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: DEBUG: <core>
[socket_info.c:589]: grep_sock_info - checking if host==us: 14==9 && [
127.0.0.1:5060] == [127.0.0.1]
Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: DEBUG: <core>
[socket_info.c:589]: grep_sock_info - checking if host==us: 14==9 && [
127.0.0.1:5060] == [127.0.0.2]
Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: DEBUG: <core>
[socket_info.c:589]: grep_sock_info - checking if host==us: 14==13 && [
127.0.0.1:5060] == [192.168.10.95]
Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: DEBUG: <core>
[socket_info.c:589]: grep_sock_info - checking if host==us: 14==13 && [
127.0.0.1:5060] == [192.168.10.55]
Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: DEBUG: <core>
[forward.c:462]: *check_self: host != me*
Aug 8 11:30:53 carlosrdcnx-laptop kamailio[16238]: WARNING: <script>: Bad
host 127.0.0.1:5060
I commented the block too and only then sipml5 was able to register itself.
What am I doing wrong here?
2. I registered a legacy softphone (twinkle) to attempt to initiate a call
in both ways, but the was something wrong with the signaling, probably some
frame decoding garbage in the buffer of the SIP message. Perhaps these
bytes are part of the frame control header but since I haven't read the RFC
(yet) I am mentioning it anyway.
tcp_send: buf=*#012�~#003�*INVITE sip:2000@df7jal23ls0d.invalid;transport=ws
SIP/2.0#015#012Record-Route:
<sip:127.0.0.1;transport=ws;r2=on;lr=on>#015#012Record-Route:
<sip:127.0.0.1;r2=on;lr=on>#015#012Via: SIP/2.0/WS
127.0.0.1;branch=z9hG4bK90a8.b1a7035e13ed19880dd12a1f4c86adbb.0#015#012Via:
SIP/2.0/UDP 127.0.0.1:5062;rport=5062;branch=z9hG4bKimixlbyp#015#012Max-Forwards:
69#015#012To: <sip:2000@127.0.0.1>#015#012From: "1000"
<sip:1000@127.0.0.1>;tag=lrtfz#015#012Call-ID:
gxsqobolphfchfq(a)carlosrdcnx-laptop.site#015#012CSeq: 654
INVITE#015#012Contact: <sip:1000@127.0.0.1:5062>#015#012Content-Type:
application/sdp#015#012Allow:
INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE#015#012Supported:
replaces,norefersub,100rel#015#012User-Agent:
Twinkle/1.4.2#015#012Content-Length:
302#015#012#015#012v=0#015#012o=twinkle 391470222 1383232165 IN IP4
127.0.0.1#015#012s=-#015#012c=IN IP4 127.0.0.1#015#012t=0 0#015#012m=audio
8008 RTP/AVP 98 97 8 0 3 101#015#012a=rtpmap:98
speex/16000#015#012a=rtpmap:97 speex/8000#015#012a=rtpmap:8
PCMA/8000#015#012a=rtpmap:0 PCMU/8000#015#012a=rtpmap:3
GSM/8000#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101
0-15#015#012a=ptime:20#015#012
3. Does Twinkle support the minimum media requirements for testing? If not,
what (Linux) softphone is suitable for this purpose?
Thanks and sorry for the long email.
Carlos.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I've started a wiki page about VoIP/IM/real-time communications with
FreedomBox
http://wiki.debian.org/FreedomBox/VoIPVideoAndInstantMessaging
This is a step towards making real-time unified communications a
feature of FreedomBox
http://freedomboxfoundation.org/
I've Bcc'd a few of the related projects that are likely to be part of
this, in particular,
- - reSIProcate (for SIP and reTurn),
- - Kamailio (for SIP),
- - Jitsi (for TurnServer and the Jitsi client),
Much of this work is already available in Debian
Going forward:
- - Exotic stuff like truly P2P Jingle Nodes and SIP RELOAD - it would
be great to get feedback from people more familiar with those things
than myself.
- - Working group for VoIP/IM/Real-time communications? For example,
some contributors may not want to follow the whole FreedomBox project,
so maybe a dedicated email list for FreedomBox VoIP/IM and
interconnection with other leading SIP/Jabber products?
- - Have I correctly represented the intended security paradigm in the
wiki page? For example, do people prefer NOT to allow regular PSTN
connectivity under any circumstances?
- - Has anyone else already started on this area?
- - For those not on the freedombox-discuss list - I won't CC you again,
so if you want to follow this thread, please come and join
freedombox-discuss
http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJQWMqYAAoJEOm1uwJp1aqDTuYQAKdlrJLZKAfYhCiVOKNTdqUN
simCseOWN6o4WBZ10yMSVsfmU+3LMNb34X7S8EIga4vJqv7jiBumdr0VAkdduPs8
MLPTxd5FxO7P6UuDUXuXlpW2yON5cF7bM/Txz6pOWP63HARvxJa5+xjOygAaQ+RL
Q9DRyhBFkqxmCUCoNAUg4NsN6eSqHEqVZ40LOk4QyvPikaatgd099wNSF0U7Ddwt
vya91SYGp5ovRPxf/47QAnYVMN8io2ZIaIG6FNSVZcox05vQ5JpcGUIIQmm3vh/Q
HnnFRihthE6QRIit01WWSt1rdD4Uiv3gNpchOq9fY8hMsfu5U9R2tSMDFPuw6/B1
tfWC4iTB1JAYhI64YiSSwdDM6w1c5mgUZ6TtpwTPtoG8Odj0AD72Yw1tq/y3hKZy
CuD9rxtpBkt/Qda5qhz0qht2fhWej4rtqjWdB867BtuzDeeppLNJRtiGNq69KvQb
cB86AH2/7JLsxnowkNuhWtVBWs+e9RHSDlX0n9FTRZuwLADFH5VwUGZCxAZkOEmk
NY+nkZdCE6oOJmRizhFyTpz/Vuu0nsEbybyZrGetvkEr9tdikzkJmRC+BEEzYOiQ
irUL6Y/A/kmDF3xacSm7eRu2Do10G5A6qoaoW3f+yAFtvPNshGgxRGnDnZjeJmyh
4QywcgzWffv2G+hMtvA8
=+gec
-----END PGP SIGNATURE-----