[SR-Users] xHTTP_PROM with older Kamailio

Marat Gareev maratkin94 at gmail.com
Sat Jul 11 03:02:27 CEST 2020


Hello,

I have a customized Kamailio (kamailio 5.1.1 (x86_64/linux)), xHTTP_PROM
<https://www.kamailio.org/docs/modules/devel/modules/xhttp_prom.html> was
released in the 5.3.0
<https://www.kamailio.org/w/kamailio-v5-3-0-release-notes/> version.

I'm trying to import the latest version of xhttp_prom to older Kamailio,
but something goes wrong.
This is simple config for test:

log_stderror=yes
> listen=5060
> debug=2
> mpath="/home/devel/build_dir/build/lib64/kamailio/modules"
> loadmodule "tm.so"
> loadmodule "sl.so"
> loadmodule "xlog.so"
> loadmodule "pv.so"




> disable_tcp=no
> tcp_accept_no_cl=yes
> loadmodule "xhttp.so"
> loadmodule "xhttp_prom.so"
> modparam("xhttp_prom", "xhttp_prom_stats", "all")
> route {
>   sl_send_reply("200", "OK");
>   exit;
> }
> event_route[xhttp:request] {
>   if (prom_check_uri()) {
>     prom_dispatch();
>   } else {
>     xhttp_reply("404", "Not Found", "text/plain", "Wrong URL $hu\n");
>   }
> }


then I send HTTP request
$ curl http://localhost:5060/metrics
but get error:

>  6(110968) CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 11
>  0(110962) ALERT: <core> [main.c:746]: handle_sigs(): child process 110967
> exited by a signal 11
>  0(110962) ALERT: <core> [main.c:749]: handle_sigs(): core was generated
>  0(110962) INFO: <core> [main.c:771]: handle_sigs(): terminating due to
> SIGCHLD

note: for http://localhost:5060/test request I get the expected message
"Wrong URL /test".

Backtrace for killed process

> (gdb) c
> Continuing.
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007fefff3ff096 in atomic_cmpxchg_int (var=0x0, old=0, new_v=1) at
> ../../core/mem/../atomic/atomic_x86.h:224
> 224 ATOMIC_FUNC_CMPXCHG(cmpxchg, "cmpxchgl %2, %1", int , int)
> (gdb) bt
> #0  0x00007fefff3ff096 in atomic_cmpxchg_int (var=0x0, old=0, new_v=1) at
> ../../core/mem/../atomic/atomic_x86.h:224
> #1  0x00007fefff3ff0e2 in futex_get (lock=0x0) at
> ../../core/mem/../futexlock.h:99
> #2  0x00007fefff4130bf in prom_metric_list_print (ctx=0x7fefff628da0
> <ctx>) at prom_metric.c:1319
> #3  0x00007fefff416468 in prom_stats_get (ctx=0x7fefff628da0 <ctx>,
> stat=0x7fefff6281f0 <xhttp_prom_stats>) at prom.c:178
> #4  0x00007fefff3d4d10 in prom_send (ctx=0x7fefff628da0 <ctx>) at
> xhttp_prom.c:361
> #5  0x00007fefff3d5faf in ki_xhttp_prom_dispatch (msg=0x7ffecb730ee0) at
> xhttp_prom.c:418
> #6  0x00007fefff3d5feb in w_prom_dispatch (msg=0x7ffecb730ee0) at
> xhttp_prom.c:428
> #7  0x0000000000461dbe in do_action (h=0x7ffecb730e00, a=0x7ff0007c7b78,
> msg=0x7ffecb730ee0) at core/action.c:1067
> #8  0x000000000046e571 in run_actions (h=0x7ffecb730e00, a=0x7ff0007c7b78,
> msg=0x7ffecb730ee0) at core/action.c:1565
> #9  0x0000000000461d2d in do_action (h=0x7ffecb730e00, a=0x7ff0007ca628,
> msg=0x7ffecb730ee0) at core/action.c:1058
> #10 0x000000000046e571 in run_actions (h=0x7ffecb730e00, a=0x7ff0007c76f8,
> msg=0x7ffecb730ee0) at core/action.c:1565
> #11 0x00007fefff62f649 in xhttp_process_request (orig_msg=0x7ff0007ebbd8,
>     new_buf=0x7ff0007cc280 "GET /metrics HTTP/1.1\r\nVia: SIP/2.0/TCP
> 127.0.0.1:37000\r\nUser-Agent: curl/7.29.0\r\nHost:
> localhost:5060\r\nAccept: */*\r\n\r\n", new_len=119) at xhttp_mod.c:298
> #12 0x00007fefff630d78 in xhttp_handler (msg=0x7ff0007ebbd8) at
> xhttp_mod.c:385
> #13 0x0000000000520141 in nonsip_msg_run_hooks (msg=0x7ff0007ebbd8) at
> core/nonsip_hooks.c:111
> #14 0x000000000058cef1 in receive_msg (buf=0x7feffee65bb0 "GET /metrics
> HTTP/1.1\r\nUser-Agent: curl/7.29.0\r\nHost: localhost:5060\r\nAccept:
> */*\r\n\r\n", len=85, rcv_info=0x7feffee658d0)
>     at core/receive.c:216
> #15 0x000000000061233f in receive_tcp_msg (tcpbuf=0x7feffee65bb0 "GET
> /metrics HTTP/1.1\r\nUser-Agent: curl/7.29.0\r\nHost:
> localhost:5060\r\nAccept: */*\r\n\r\n", len=85, rcv_info=0x7feffee658d0,
>     con=0x7feffee658b8) at core/tcp_read.c:1379
> #16 0x000000000061479e in tcp_read_req (con=0x7feffee658b8,
> bytes_read=0x7ffecb731c7c, read_flags=0x7ffecb731c78) at
> core/tcp_read.c:1611
> #17 0x00000000006174e9 in handle_io (fm=0x7ff0007d9720, events=1, idx=-1)
> at core/tcp_read.c:1785
> #18 0x00000000006069b4 in io_wait_loop_epoll (h=0xaa76c0 <io_w>, t=2,
> repeat=0) at core/io_wait.h:1065
> #19 0x00000000006194ff in tcp_receive_loop (unix_sock=14) at
> core/tcp_read.c:1955
> #20 0x00000000004f1a43 in tcp_init_children () at core/tcp_main.c:4853
> #21 0x0000000000423f99 in main_loop () at main.c:1716
> #22 0x000000000042a5ee in main (argc=9, argv=0x7ffecb7323b8) at main.c:2646
> (gdb)
> (gdb) p 'prom_metric.c'::prom_lock
> $4 = (gen_lock_t *) 0x0


If I understood correctly, the problem is in an uninitialized variable
static gen_lock_t *prom_lock = NULL; /* Lock to protect Prometheus metrics.
*/

So, is it possible to import xHTTP_PROM to older Kamailio? I will be glad
for any advice.

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200711/af77e8c7/attachment.htm>


More information about the sr-users mailing list