Module: kamailio
Branch: master
Commit: 9328918897d44bec0f0a393af91483c2413a1446
URL: https://github.com/kamailio/kamailio/commit/9328918897d44bec0f0a393af91483c…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2015-01-07T18:08:35+01:00
core: memset 0 the struct in first line parsing; split type and flags
- initialize to 0 first line struct msg_start_t in parse_first_line()
- split field int type in short type and short flags to be able to store
more info about first line without changes in other places of existing code
- set in flags if the protocol in first line is sip or http - useful to
avoid string comparison whenever needed to get the two very used
protocols
---
Modified: parser/parse_fline.c
Modified: parser/parse_fline.h
---
Diff: https://github.com/kamailio/kamailio/commit/9328918897d44bec0f0a393af91483c…
Patch: https://github.com/kamailio/kamailio/commit/9328918897d44bec0f0a393af91483c…
---
diff --git a/parser/parse_fline.c b/parser/parse_fline.c
index dbbe4de..861b5fd 100644
--- a/parser/parse_fline.c
+++ b/parser/parse_fline.c
@@ -45,6 +45,11 @@
#include "../mem/mem.h"
#include "../ut.h"
+/* flags for first line
+ * - stored on a short field (16 flags) */
+#define FLINE_FLAG_PROTO_SIP (1<<0)
+#define FLINE_FLAG_PROTO_HTTP (1<<1)
+
int http_reply_parse = 0;
/* grammar:
@@ -56,7 +61,7 @@ int http_reply_parse = 0;
/* parses the first line, returns pointer to next line & fills fl;
also modifies buffer (to avoid extra copy ops) */
-char* parse_first_line(char* buffer, unsigned int len, struct msg_start * fl)
+char* parse_first_line(char* buffer, unsigned int len, struct msg_start* fl)
{
char *tmp;
@@ -77,6 +82,7 @@ char* parse_first_line(char* buffer, unsigned int len, struct msg_start * fl)
*/
+ memset(fl, 0, sizeof(struct msg_start));
offset = 0;
end=buffer+len;
/* see if it's a reply (status) */
@@ -97,6 +103,7 @@ char* parse_first_line(char* buffer, unsigned int len, struct msg_start * fl)
strncasecmp( tmp+1, SIP_VERSION+1, SIP_VERSION_LEN-1)==0 &&
(*(tmp+SIP_VERSION_LEN)==' ')) {
fl->type=SIP_REPLY;
+ fl->flags|=FLINE_FLAG_PROTO_SIP;
fl->u.reply.version.len=SIP_VERSION_LEN;
tmp=buffer+SIP_VERSION_LEN;
} else if (http_reply_parse != 0 &&
@@ -111,6 +118,7 @@ char* parse_first_line(char* buffer, unsigned int len, struct msg_start * fl)
* - the message is marked as SIP_REPLY (ugly)
*/
fl->type=SIP_REPLY;
+ fl->flags|=FLINE_FLAG_PROTO_HTTP;
fl->u.reply.version.len=HTTP_VERSION_LEN+1 /*include last digit*/;
tmp=buffer+HTTP_VERSION_LEN+1 /* last digit */;
} else IFISMETHOD( INVITE, 'I' )
@@ -223,6 +231,22 @@ char* parse_first_line(char* buffer, unsigned int len, struct msg_start * fl)
fl->u.request.version.len=tmp-third;
fl->len=nl-buffer;
+ if (fl->type==SIP_REQUEST) {
+ if(fl->u.request.version.len >= SIP_VERSION_LEN
+ && (fl->u.request.version.s[0]=='S'
+ || fl->u.request.version.s[0]=='s')
+ && !strncasecmp(fl->u.request.version.s+1,
+ SIP_VERSION+1, SIP_VERSION_LEN-1)) {
+ fl->flags|=FLINE_FLAG_PROTO_SIP;
+ } else if(fl->u.request.version.len >= HTTP_VERSION_LEN
+ && (fl->u.request.version.s[0]=='H'
+ || fl->u.request.version.s[0]=='h')
+ && !strncasecmp(fl->u.request.version.s+1,
+ HTTP_VERSION+1, HTTP_VERSION_LEN-1)) {
+ fl->flags|=FLINE_FLAG_PROTO_HTTP;
+ }
+ }
+
return nl;
error:
@@ -245,3 +269,12 @@ char* parse_first_line(char* buffer, unsigned int len, struct msg_start * fl)
nl=eat_line(buffer,len);
return nl;
}
+
+char* parse_fline(char* buffer, char* end, struct msg_start* fl)
+{
+ if(end<=buffer) {
+ /* make it throw error via parse_first_line() for consistency */
+ return parse_first_line(buffer, 0, fl);
+ }
+ return parse_first_line(buffer, (unsigned int)(end-buffer), fl);
+}
diff --git a/parser/parse_fline.h b/parser/parse_fline.h
index 7564b9f..62873f5 100644
--- a/parser/parse_fline.h
+++ b/parser/parse_fline.h
@@ -69,7 +69,8 @@
#define PUBLISH_LEN 7
struct msg_start {
- int type; /*!< Type of the Message - Request/Response */
+ short type; /*!< Type of the message - request/response */
+ short flags; /*!< First line flags */
int len; /*!< length including delimiter */
union {
struct {
Hi,
I'm running 4.2:ca60c77acddc13d36ab691f8cac1f566323f6d86 and seem to be
able to dependably crash Kamailio by sending the following JSONRPC
stanza to the jsonrpc-s module:
{"jsonrpc":2,"id":"126491c7ce1e1ba1552f18ebf1271f19","method":"core.version"}\n
The number of HTTP requests needed to crash it varies, but seems to
generally be about 8-10 on my system:
Jan 7 02:32:04 localhost /usr/local/sbin/kamailio[2785]: INFO:
[R-XHTTP-REQUEST:<null>] -> Handling JSON RPC request: /csrp_rpc/
Jan 7 02:32:05 localhost /usr/local/sbin/kamailio[2791]: CRITICAL:
<core> [pass_fd.c:293]: receive_fd(): EOF on 59
Jan 7 02:32:05 localhost /usr/local/sbin/kamailio[2734]: ALERT: <core>
[main.c:784]: handle_sigs(): child process 2785 exited by a signal 11
Jan 7 02:32:05 localhost /usr/local/sbin/kamailio[2734]: ALERT: <core>
[main.c:787]: handle_sigs(): core was generated
The core dump says it's because jsonrpc_dispatch() is being invoked with
two empty parameters:
#0 0x00007fc2b0b6f171 in __strlen_sse2 () from /lib64/libc.so.6
#1 0x00007fc2a6ffea72 in jsonrpc_dispatch (msg=0x7fff5721ceb0, s1=0x0,
s2=0x0)
at jsonrpc-s_mod.c:943
#2 0x000000000041d29b in do_action (h=0x7fff5721cdd0, a=0x7fc2b051b2c0,
msg=0x7fff5721ceb0) at action.c:1088
#3 0x00000000004299b1 in run_actions (h=0x7fff5721cdd0, a=0x7fc2b051b070,
msg=0x7fff5721ceb0) at action.c:1583
#4 0x000000000041d204 in do_action (h=0x7fff5721cdd0, a=0x7fc2b051b9d0,
msg=0x7fff5721ceb0) at action.c:1079
#5 0x00000000004299b1 in run_actions (h=0x7fff5721cdd0, a=0x7fc2b051b9d0,
msg=0x7fff5721ceb0) at action.c:1583
#6 0x00007fc2a720ad2b in xhttp_process_request (orig_msg=0x7fc2b0561438,
new_buf=0x7fc2b051d550 "POST /csrp_rpc/ HTTP/1.1\r\nVia:
SIP/2.0/TCP 172.30.110.4:42861\r\nHost: 172.30.110.4:5060\r\nConnection:
close\r\nTransfer-Encoding:
chunked\r\n\r\n{\"jsonrpc\":2,\"id\":\"126491c7ce1e1ba1552f18ebf1271f19\",\"method\":\""...,
new_len=215) at xhttp_mod.c:284
#7 0x00007fc2a720bd98 in xhttp_handler (msg=0x7fc2b0561438) at
xhttp_mod.c:359
#8 0x00000000004de163 in nonsip_msg_run_hooks (msg=0x7fc2b0561438)
at nonsip_hooks.c:125
#9 0x0000000000506999 in receive_msg (
buf=0x2a9d5a0 "POST /csrp_rpc/ HTTP/1.1\r\nHost:
172.30.110.4:5060\r\nConnection: close\r\nTransfer-Encoding:
chunked\r\n\r\n{\"jsonrpc\":2,\"id\":\"126491c7ce1e1ba1552f18ebf1271f19\",\"method\":\"core.version\"}\n",
len=178,
...
I'll see what changes I can make to try to get it to not crash.
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Hello,
it appears that the traffic with commits on personal branches is
increasing, therefore I am trying to figure out if there is a need to
filter the email notifications (being suggested to me by someone here,
as well).
I extended the notification script
(https://github.com/miconda/gitpushub) to be able to filter on branch
name and send email notifications to different addresses or skip notifying.
If people think there is too much traffic with notification from
personal branches, we can update to:
1) send notifications of commits to official branches (master, 4.2, 4.1,
and older releases) to sr-dev
2) for the rest of commits, several options
a) skip notifying them
b) create another mailing list where to send all commits
notifications (including for official branches)
c) decide case by case - a dev can request to skip notifications to
its personal branches (if she/he uses them extensevely) or the community
asks to ingnore some particular branches (if it appears to be a lot of
no important activity)
If you think of other combinations, don't hesitate to propose here.
At this moment I tend for 1, 2b).
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda