[sr-dev] [kamailio/kamailio] async_http_client crash (#2286)
Alex Balashov
notifications at github.com
Wed Apr 15 17:29:47 CEST 2020
Version: 5.3.3 `065668`
Platform: CentOS 7 (3.10.0-862.14.4.el7.x86_64)
I seem to have a persistent intermittent crash on all five gateways which use `http_async_client` to query an HTTP API.
In all cases, the crash is on attempt to access or reference an AVP called `$avp(is_subscribe)`:
```
Program terminated with signal 11, Segmentation fault.
#0 0x00000000005d479b in match_by_name (avp=0xabcdefed, id=45, name=0x7fff9379c668)
at core/usr_avp.c:378
378 if (id==avp->id && avp->flags&AVP_NAME_STR &&
hMissing separate debuginfos, use: debuginfo-install libuuid-2.23.2-52.el7_5.1.x86_64 nss-pem-1.0.3-4.el7.x86_64
(gdb) where
#0 0x00000000005d479b in match_by_name (avp=0xabcdefed, id=45, name=0x7fff9379c668)
at core/usr_avp.c:378
#1 0x00000000005d54bf in search_next_avp (s=0x7fff9379c660, val=0x7fff9379c630)
at core/usr_avp.c:499
#2 0x00000000005d4f04 in search_avp (ident=..., val=0x7fff9379c630, state=0x7fff9379c660)
at core/usr_avp.c:465
#3 0x00000000005d4913 in search_first_avp (flags=1, name=..., val=0x7fff9379c630,
s=0x7fff9379c660) at core/usr_avp.c:414
#4 0x00007f3f6ba529fd in ops_is_avp_set (msg=0xb04f60 <_faked_msg>, ap=0x7f3f73296ed8)
at avpops_impl.c:1821
#5 0x00007f3f6ba60d47 in w_is_avp_set (msg=0xb04f60 <_faked_msg>, param=0x7f3f73296ed8 "",
op=0x0) at avpops.c:1059
#6 0x0000000000480f3d in do_action (h=0x7fff9379ce70, a=0x7f3f732a8b30,
msg=0xb04f60 <_faked_msg>) at core/action.c:1077
#7 0x000000000048da7c in run_actions (h=0x7fff9379ce70, a=0x7f3f732a8b30,
msg=0xb04f60 <_faked_msg>) at core/action.c:1576
#8 0x000000000048e13d in run_actions_safe (h=0x7fff9379dae0, a=0x7f3f732a8b30,
msg=0xb04f60 <_faked_msg>) at core/action.c:1640
#9 0x0000000000438ff3 in rval_get_int (h=0x7fff9379dae0, msg=0xb04f60 <_faked_msg>,
i=0x7fff9379d318, rv=0x7f3f732a8d70, cache=0x0) at core/rvalue.c:915
#10 0x000000000043d5a3 in rval_expr_eval_int (h=0x7fff9379dae0, msg=0xb04f60 <_faked_msg>,
res=0x7fff9379d318, rve=0x7f3f732a8d68) at core/rvalue.c:1913
#11 0x000000000043d9f6 in rval_expr_eval_int (h=0x7fff9379dae0, msg=0xb04f60 <_faked_msg>,
res=0x7fff9379d7cc, rve=0x7f3f732a9598) at core/rvalue.c:1921
#12 0x000000000048097b in do_action (h=0x7fff9379dae0, a=0x7f3f732aa9c0,
msg=0xb04f60 <_faked_msg>) at core/action.c:1047
#13 0x000000000048da7c in run_actions (h=0x7fff9379dae0, a=0x7f3f732aa9c0,
msg=0xb04f60 <_faked_msg>) at core/action.c:1576
#14 0x000000000048e205 in run_top_route (a=0x7f3f732aa9c0, msg=0xb04f60 <_faked_msg>, c=0x0)
at core/action.c:1661
#15 0x00007f3f705f7d0e in async_http_cb (reply=0x7f3f2b7ee620, param=0x7f3f2b7eca18)
at async_http.c:256
#16 0x00007f3f705f0dab in check_multi_info (g=0x7f3f2abeb9e8) at http_multi.c:597
#17 0x00007f3f705e84ec in event_cb (fd=6, kind=2, userp=0x1d7cdf0) at http_multi.c:145
#18 0x00007f3f70131a14 in event_process_active_single_queue (activeq=0x1c6f820, base=0x1d3ad90)
at event.c:1350
#19 event_process_active (base=<optimized out>) at event.c:1420
#20 event_base_loop (base=0x1d3ad90, flags=0) at event.c:1621
#21 0x00007f3f705f490f in async_http_run_worker (worker=0x7f3f2abd1bb0) at async_http.c:92
#22 0x00007f3f705dcb17 in child_init (rank=0) at http_async_client_mod.c:366
#23 0x000000000057a810 in init_mod_child (m=0x7f3f73245168, rank=0) at core/sr_module.c:780
#24 0x000000000057a4ac in init_mod_child (m=0x7f3f73245d58, rank=0) at core/sr_module.c:776
#25 0x000000000057a4ac in init_mod_child (m=0x7f3f73246340, rank=0) at core/sr_module.c:776
#26 0x000000000057a4ac in init_mod_child (m=0x7f3f732467f8, rank=0) at core/sr_module.c:776
#27 0x000000000057a4ac in init_mod_child (m=0x7f3f73246e38, rank=0) at core/sr_module.c:776
#28 0x000000000057a4ac in init_mod_child (m=0x7f3f73247210, rank=0) at core/sr_module.c:776
#29 0x000000000057a4ac in init_mod_child (m=0x7f3f73247978, rank=0) at core/sr_module.c:776
#30 0x000000000057a4ac in init_mod_child (m=0x7f3f73247da0, rank=0) at core/sr_module.c:776
#31 0x000000000057af5a in init_child (rank=0) at core/sr_module.c:825
#32 0x0000000000426bc1 in main_loop () at main.c:1753
#33 0x000000000042e63a in main (argc=13, argv=0x7fff9379edb8) at main.c:2802
```
Most recently, it is here:
```
route {
$avp(is_subscribe) = 0;
...
$http_req(method) = 'GET';
$http_req(suspend) = 1;
$http_req(hdr) = "x-api-key: " + $sel(cfg_get.api.whitelist_key);
t_newtran();
http_async_query("https://some_host/check_ip_in_whi
telist?ip=$(si{s.escape.common})", "WHITELIST_CHECK");
}
...
route[WHITELIST_CHECK] {
if(!is_avp_set("$avp(is_subscribe)")) {
xlog("L_INFO", "[R-HTTP-REPLY:$ci] !> AVP is_subscribe is undefined -- cannot process further\n");
sl_send_reply("500", "Internal Server Error");
exit;
}
```
However, adding `is_avp_set()` was my attempt to put a safe-guard around unsafe access of this AVP. It didn't work:
```
(gdb) print *name
$1 = {s = 0x7f3f73261835 "is_subscribe)", len = 12}
(gdb) print avp
$2 = (avp_t *) 0xabcdefed
(gdb) print avp->id
Cannot access memory at address 0xabcdefed
```
Note that I am making the assumption above that AVPs created in the main request route will be available in the `http_async_client` callback, because it is just a suspended TM transaction underneath -- right? So, transaction-persistent variables such as AVP should be visible throughout the lifetime of the transaction just as for a conventional async TM transaction, I would think.
Digging further into the mesage being handled in `async_http_cb()`, it is always a normal HTTP `200 OK` reply:
```
(gdb) set print elements 0
(gdb) frame 15
#15 0x00007f3f705f7d0e in async_http_cb (reply=0x7f3f2b7ee620, param=0x7f3f2b7eca18)
at async_http.c:256
256 if (run_top_route(act, fmsg, 0)<0) {
(gdb) print *reply
$5 = {retcode = 200, result = 0x7f3f2b7ec560, error = '\000' <repeats 255 times>}
(gdb) print *(reply->result)
$6 = {
s = 0x7f3f2b7ee798 "HTTP/1.1 200 OK\r\nContent-Type: application/json\r\nContent-Length: 16\r\nConnection: keep-alive\r\nDate: Wed, 15 Apr 2020 15:06:52 GMT\r\nx-amzn-RequestId: d3a44941-e0c4-4cb9-9144-ea54d929c300\r\nx-amz-apigw-id: LCJqBF7CIAMFXCw=\r\nX-Amzn-Trace-Id: Root=1-5e97230c-4fe1af7d072275d95c231a4c;Sampled=0\r\nX-Cache: Miss from cloudfront\r\nHia: 1.1 ade18dc841d2e1cc8ef49611c5d4c93e.cloudfront.net (CloudFront)\r\nX-Amz-Cf-Pop: IAD89-C2\r\nX-Amz-Cf-Id: 3s1S2kvOgL7L4ZKMlWwQnfIxHmWFGz0PHbcNFefYA1tZ1j0AGy3JHg==\r\n\r\n{\"status\":false}\300\300\300\300", len = 504}
```
Any insights would be appreciated! These crashes are happening basically hourly from nowhere, after over a year of undisturbed operation.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2286
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20200415/881bc831/attachment.html>
More information about the sr-dev
mailing list