sr-dev May 2015

sr-dev@lists.kamailio.org

34 participants
297 discussions

building app_lua module fails in debian jessie
by Juha Heinanen 04 May '15

04 May '15

i tried to build kamailio from latest master on debian jessie, but building app_lua module failed: ls: cannot access /usr/local/lib/liblua*: No such file or directory ls: cannot access /usr/local/lib/liblua*: No such file or directory ls: cannot access /usr/local/lib/liblua*: No such file or directory ls: cannot access /usr/local/lib/liblua*: No such file or directory CC (cc) [M app_lua.so] app_lua_mod.o In file included from app_lua_mod.c:35:0: app_lua_api.h:27:17: fatal error: lua.h: No such file or directory #include <lua.h> ^ compilation terminated. ../../Makefile.rules:97: recipe for target 'app_lua_mod.o' failed in debian jessie, lua.h is in /usr/include/lua5.1 and the libs are installed like this (amd64 arch): $ dpkg -L liblua5.1-0 /. /usr /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/liblua5.1-c++.so.0.0.0 /usr/lib/x86_64-linux-gnu/liblua5.1.so.0.0.0 /usr/share /usr/share/doc /usr/share/doc/liblua5.1-0 /usr/share/doc/liblua5.1-0/copyright /usr/share/doc/liblua5.1-0/README.Debian.gz /usr/share/doc/liblua5.1-0/changelog.Debian.gz /usr/share/doc/liblua5.1-0/changelog.gz /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 /usr/lib/x86_64-linux-gnu/liblua5.1-c++.so.0 i noticed that there was some major changes in the Makefile 22 days ago, which may have caused this. earlier i have had no trouble with app_lua build in this environment. -- juha

3 7

git:master:e731e669: jsonrpc-s: extended docs for fifo_name parameter
by Daniel-Constantin Mierla 04 May '15

04 May '15

Module: kamailio Branch: master Commit: e731e6693c7a20ab1ddc0c2f80e3ae2d4ed06af6 URL: https://github.com/kamailio/kamailio/commit/e731e6693c7a20ab1ddc0c2f80e3ae2… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: 2015-05-04T21:22:51+02:00 jsonrpc-s: extended docs for fifo_name parameter --- Modified: modules/jsonrpc-s/README Modified: modules/jsonrpc-s/doc/jsonrpc-s_admin.xml --- Diff: https://github.com/kamailio/kamailio/commit/e731e6693c7a20ab1ddc0c2f80e3ae2… Patch: https://github.com/kamailio/kamailio/commit/e731e6693c7a20ab1ddc0c2f80e3ae2… --- diff --git a/modules/jsonrpc-s/README b/modules/jsonrpc-s/README index 02c3a52..5d1e328 100644 --- a/modules/jsonrpc-s/README +++ b/modules/jsonrpc-s/README @@ -171,7 +171,8 @@ modparam("jsonrpc-s", "transport", 1) 3.3. fifo_name (str) The name of the FIFO file to be created for listening and reading - external commands. + external commands. If the given path is not absolute, the fifo file is + created relative to run_dir (global parameter). Default value is NONE. diff --git a/modules/jsonrpc-s/doc/jsonrpc-s_admin.xml b/modules/jsonrpc-s/doc/jsonrpc-s_admin.xml index 3465301..6c9ef1c 100644 --- a/modules/jsonrpc-s/doc/jsonrpc-s_admin.xml +++ b/modules/jsonrpc-s/doc/jsonrpc-s_admin.xml @@ -138,7 +138,8 @@ modparam("jsonrpc-s", "transport", 1) <title><varname>fifo_name</varname> (str)</title> <para> The name of the FIFO file to be created for listening and - reading external commands. + reading external commands. If the given path is not absolute, + the fifo file is created relative to run_dir (global parameter). </para> <para> <emphasis>

1 0

git:master:d7c1520a: jsonrpc-s: take in consideration run_dir value if fifo path is not absolute
by Daniel-Constantin Mierla 04 May '15

04 May '15

Module: kamailio Branch: master Commit: d7c1520ad4dd83e949ebe1b64ec07c6963982390 URL: https://github.com/kamailio/kamailio/commit/d7c1520ad4dd83e949ebe1b64ec07c6… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: 2015-05-04T21:20:42+02:00 jsonrpc-s: take in consideration run_dir value if fifo path is not absolute --- Modified: modules/jsonrpc-s/jsonrpc-s_mod.c --- Diff: https://github.com/kamailio/kamailio/commit/d7c1520ad4dd83e949ebe1b64ec07c6… Patch: https://github.com/kamailio/kamailio/commit/d7c1520ad4dd83e949ebe1b64ec07c6… --- diff --git a/modules/jsonrpc-s/jsonrpc-s_mod.c b/modules/jsonrpc-s/jsonrpc-s_mod.c index eb84b62..a5c877b 100644 --- a/modules/jsonrpc-s/jsonrpc-s_mod.c +++ b/modules/jsonrpc-s/jsonrpc-s_mod.c @@ -893,6 +893,10 @@ static void jsonrpc_clean_context(jsonrpc_ctx_t* ctx) static int mod_init(void) { + int sep; + int len; + char *p; + /* bind the XHTTP API */ if(jsonrpc_transport==0 || jsonrpc_transport==1) { if (xhttp_load_api(&xhttp_api) < 0) { @@ -905,6 +909,28 @@ static int mod_init(void) } } if(jsonrpc_transport==0 || jsonrpc_transport==2) { + if(jsonrpc_fifo != NULL && *jsonrpc_fifo!=0) { + if(*jsonrpc_fifo != '/') { + if(runtime_dir!=NULL && *runtime_dir!=0) { + len = strlen(runtime_dir); + sep = 0; + if(runtime_dir[len-1]!='/') { + sep = 1; + } + len += sep + strlen(jsonrpc_fifo); + p = pkg_malloc(len + 1); + if(p==NULL) { + LM_ERR("no more pkg\n"); + return -1; + } + strcpy(p, runtime_dir); + if(sep) strcat(p, "/"); + strcat(p, jsonrpc_fifo); + jsonrpc_fifo = p; + LM_DBG("fifo path is [%s]\n", jsonrpc_fifo); + } + } + } if(jsonrpc_init_fifo_file()<0) { if(jsonrpc_transport==2) { LM_ERR("cannot initialize fifo transport\n");

1 0

kamcli - kamailio command line control tool
by Daniel-Constantin Mierla 04 May '15

04 May '15

Hello, we just published a new command line tool for Kamailio management, named now kamcli, available at: * https://github.com/asipto/kamcli It is written in Python and adapted from a tool provided originally by a subcontractor for a specific deployment. While not being Python developers here, the benefits and flexibility proved extremely good. At this stage it is more an attempt to see if the community finds it useful and worth to get it developed further as part of Kamailio project. Short about the benefits/flexibility: - python is by default installed on OSes (including Mac OS X) (as opposite to Lua, for example) - became rather fast since Google invested in it - lot more knowledge base and developers out there (as opposite to Lua or Perl), along with tons of extensions - implementation is based on a CLI framework (Click) that makes it extremely easy to add new commands in a plugin-like fashion, therefore is easy to have custom commands when having specific needs (e.g., managing a custom database table used in kamailio.cfg via sqlops => add a new cmd_xyz.py in commands subfolder, without touching other files, not even the config) - help message is embedded in the command code file, making it easier to document commands - easy to validate parameters as well as format the output - handling kamcli configuration file options is also easy (ini format) One of my reasons of pushing this out was in the perspective of deprecating MI and working with JSONRPC fifo from command line -- I couldn't find easy ways to manage json docs with shell and common tools (e.g., cat, echo, grep, awk) only. Kamcli has implemented the JSONRPC over fifo command (see also jsonrpc-s kamailio module). Still, given the old initial implementation, at this moment, kamcli is relying on MI via fifo (mi_fifo) for some of the commands (e.g., dumping usrloc records from memory) -- (Just as side note: perhaps here we need to do a mapping, because name of commands are different, if we want to make a 'ctl transport agnostic' tool.) Here are few things to decide: - does it sound useful and are people finding it worth to develop it further? - what about the name, is it ok? Another one? If worth developing and deciding on the name, then the plan is to host the project on kamailio organization on github so each kamailio developer can code on it (it won't be inside kamailio source code tree, but a separate project inside same organization). So far, couple of commands were implemented when comparing with kamctl: - subscriber management (kamctl add/rm/passwd...) - user location management (kamctl ul ...) - database querying (kamctl db ...) - statistics (kamctl stats ...) - mi commands (kamctl mi ...) - jsonrpc commands (not in kamctl) While cross posted for the sake of getting the info to everyone in the community, let's have further discussions on sr-dev. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com

3 3

ndb_redis compilation issues
by Alex Balashov 03 May '15

03 May '15

Hello, I have a problem with building hiredis + ndb_redis. The problem is with hiredis rather than ndb_redis directly, but I am not sure how to best handle it and would be grateful for any advice. The problem is that somewhere with the recent Hiredis 0.13.0 release[1], they came to use the following nested struct in the hiredis.h header: --- /* Context for a connection to Redis */ typedef struct redisContext { ... struct { char *path; } unix; /* line 158 */ ... } redisContext; --- It appears the GNU compilers do not like the use of 'unix' as an identifier: --- [root@proxy ndb_redis]# make CC (gcc) [M ndb_redis.so] ndb_redis_mod.o In file included from redis_client.h:27, from ndb_redis_mod.c:38: /usr/local/include/hiredis/hiredis.h:158: error: expected identifier or ‘(’ before numeric constant make: *** [ndb_redis_mod.o] Error 1 --- Indeed, a quick test against a normal gcc installation on CentOS 6.6 reveals that 'unix' is a defined constant: --- [root@proxy ~]# echo -e "#include <stdio.h>\n#include <stdlib.h>\nint main() { printf(\"%d\\\n\", unix); return 1; }" > ns.c [root@proxy ~]# make ns cc ns.c -o ns [root@proxy ~]# ./ns 1 --- The authors of hiredis themselves note this problem in a recent commit: --- commit d8145d79ce715054980938c751067ebaa541573c Author: Jan-Erik Rediger <janerik(a)fnordig.de> Date: Thu Apr 16 22:51:32 2015 +0200 Always compile with C99 standard. Turns out: gnu9x defines `unix` to 1, making it unusable as a variable name. --- So, their solution is to compile with -std=c99, which works fine. The problem is that a) ndb_redis isn't compiled with -std=c99 and b) my superficial effort at making it compile that way did not bear fruit: --- [root@rproxy01 ndb_redis]# make MOD_CFLAGS='-fPIC -DPIC $(CFLAGS) -std=c99' CC (gcc) [M ndb_redis.so] ndb_redis_mod.o In file included from ../../parser/../mem/shm_mem.h:47, from ../../parser/../ut.h:64, from ../../parser/../ip_addr.h:50, from ../../parser/msg_parser.h:61, from ../../sr_module.h:62, from ndb_redis_mod.c:32: /usr/include/sys/ipc.h:25:3: warning: #warning "Files using this header must be compiled with _SVID_SOURCE or _XOPEN_SOURCE" In file included from ../../parser/../mem/../atomic/atomic_native.h:53, from ../../parser/../mem/../futexlock.h:44, from ../../parser/../mem/../lock_ops.h:85, from ../../parser/../mem/shm_mem.h:75, from ../../parser/../ut.h:64, from ../../parser/../ip_addr.h:50, from ../../parser/msg_parser.h:61, from ../../sr_module.h:62, from ndb_redis_mod.c:32: ../../parser/../mem/../atomic/atomic_x86.h: In function ‘atomic_inc_int’: ../../parser/../mem/../atomic/atomic_x86.h:226: error: ‘asm’ undeclared (first use in this function) ../../parser/../mem/../atomic/atomic_x86.h:226: error: (Each undeclared identifier is reported only once ../../parser/../mem/../atomic/atomic_x86.h:226: error: for each function it appears in.) ../../parser/../mem/../atomic/atomic_x86.h:226: error: expected ‘;’ before ‘volatile’ ../../parser/../mem/../atomic/atomic_x86.h: In function ‘atomic_dec_int’: ../../parser/../mem/../atomic/atomic_x86.h:227: error: ‘asm’ undeclared (first use in this function) ../../parser/../mem/../atomic/atomic_x86.h:227: error: expected ‘;’ before ‘volatile’ ../../parser/../mem/../atomic/atomic_x86.h: In function ‘atomic_and_int’: ../../parser/../mem/../atomic/atomic_x86.h:228: error: ‘asm’ undeclared (first use in this function) ../../parser/../mem/../atomic/atomic_x86.h:228: error: expected ‘;’ before ‘volatile’ ../../parser/../mem/../atomic/atomic_x86.h: In function ‘atomic_or_int’: ../../parser/../mem/../atomic/atomic_x86.h:229: error: ‘asm’ undeclared (first use in this function) ../../parser/../mem/../atomic/atomic_x86.h:229: error: expected ‘;’ before ‘volatile’ ../../parser/../mem/../atomic/atomic_x86.h: In function ‘atomic_inc_and_test_int’: ../../parser/../mem/../atomic/atomic_x86.h:230: error: ‘asm’ undeclared (first use in this function) ../../parser/../mem/../atomic/atomic_x86.h:230: error: expected ‘;’ before ‘volatile’ ../../parser/../mem/../atomic/atomic_x86.h: In function ‘atomic_dec_and_test_int’: ../../parser/../mem/../atomic/atomic_x86.h:231: error: ‘asm’ undeclared (first use in this function) ../../parser/../mem/../atomic/atomic_x86.h:231: error: expected ‘;’ before ‘volatile’ ../../parser/../mem/../atomic/atomic_x86.h: In function ‘atomic_get_and_set_int’: ../../parser/../mem/../atomic/atomic_x86.h:232: error: ‘asm’ undeclared (first use in this function) ../../parser/../mem/../atomic/atomic_x86.h:232: error: expected ‘;’ before ‘volatile’ ../../parser/../mem/../atomic/atomic_x86.h: In function ‘atomic_cmpxchg_int’: ../../parser/../mem/../atomic/atomic_x86.h:233: error: ‘asm’ undeclared (first use in this function) ../../parser/../mem/../atomic/atomic_x86.h:233: error: expected ‘;’ before ‘volatile’ ../../parser/../mem/../atomic/atomic_x86.h: In function ‘atomic_add_int’: ../../parser/../mem/../atomic/atomic_x86.h:234: error: ‘asm’ undeclared (first use in this function) ../../parser/../mem/../atomic/atomic_x86.h:234: error: expected ‘;’ before ‘volatile’ ../../parser/../mem/../atomic/atomic_x86.h: In function ‘atomic_inc_long’: ../../parser/../mem/../atomic/atomic_x86.h:236: error: ‘asm’ undeclared (first use in this function) ../../parser/../mem/../atomic/atomic_x86.h:236: error: expected ‘;’ before ‘volatile’ ../../parser/../mem/../atomic/atomic_x86.h: In function ‘atomic_dec_long’: ../../parser/../mem/../atomic/atomic_x86.h:237: error: ‘asm’ undeclared (first use in this function) ../../parser/../mem/../atomic/atomic_x86.h:237: error: expected ‘;’ before ‘volatile’ ../../parser/../mem/../atomic/atomic_x86.h: In function ‘atomic_and_long’: ../../parser/../mem/../atomic/atomic_x86.h:238: error: ‘asm’ undeclared (first use in this function) ../../parser/../mem/../atomic/atomic_x86.h:238: error: expected ‘;’ before ‘volatile’ ../../parser/../mem/../atomic/atomic_x86.h: In function ‘atomic_or_long’: ../../parser/../mem/../atomic/atomic_x86.h:239: error: ‘asm’ undeclared (first use in this function) ../../parser/../mem/../atomic/atomic_x86.h:239: error: expected ‘;’ before ‘volatile’ ../../parser/../mem/../atomic/atomic_x86.h: In function ‘atomic_inc_and_test_long’: ../../parser/../mem/../atomic/atomic_x86.h:240: error: ‘asm’ undeclared (first use in this function) ../../parser/../mem/../atomic/atomic_x86.h:240: error: expected ‘;’ before ‘volatile’ ../../parser/../mem/../atomic/atomic_x86.h: In function ‘atomic_dec_and_test_long’: ../../parser/../mem/../atomic/atomic_x86.h:241: error: ‘asm’ undeclared (first use in this function) ../../parser/../mem/../atomic/atomic_x86.h:241: error: expected ‘;’ before ‘volatile’ ../../parser/../mem/../atomic/atomic_x86.h: In function ‘atomic_get_and_set_long’: ../../parser/../mem/../atomic/atomic_x86.h:242: error: ‘asm’ undeclared (first use in this function) ../../parser/../mem/../atomic/atomic_x86.h:242: error: expected ‘;’ before ‘volatile’ ../../parser/../mem/../atomic/atomic_x86.h: In function ‘atomic_cmpxchg_long’: ../../parser/../mem/../atomic/atomic_x86.h:243: error: ‘asm’ undeclared (first use in this function) ../../parser/../mem/../atomic/atomic_x86.h:243: error: expected ‘;’ before ‘volatile’ ../../parser/../mem/../atomic/atomic_x86.h: In function ‘atomic_add_long’: ../../parser/../mem/../atomic/atomic_x86.h:244: error: ‘asm’ undeclared (first use in this function) ../../parser/../mem/../atomic/atomic_x86.h:244: error: expected ‘;’ before ‘volatile’ ../../parser/../mem/../atomic/atomic_x86.h: In function ‘mb_atomic_set_int’: ../../parser/../mem/../atomic/atomic_x86.h:299: error: ‘asm’ undeclared (first use in this function) ../../parser/../mem/../atomic/atomic_x86.h:299: error: expected ‘;’ before ‘volatile’ ../../parser/../mem/../atomic/atomic_x86.h: In function ‘mb_atomic_set_long’: ../../parser/../mem/../atomic/atomic_x86.h:312: error: ‘asm’ undeclared (first use in this function) ../../parser/../mem/../atomic/atomic_x86.h:312: error: expected ‘;’ before ‘volatile’ ../../parser/../mem/../atomic/atomic_x86.h: In function ‘mb_atomic_get_int’: ../../parser/../mem/../atomic/atomic_x86.h:331: error: ‘asm’ undeclared (first use in this function) ../../parser/../mem/../atomic/atomic_x86.h:331: error: expected ‘;’ before ‘volatile’ ../../parser/../mem/../atomic/atomic_x86.h: In function ‘mb_atomic_get_long’: ../../parser/../mem/../atomic/atomic_x86.h:342: error: ‘asm’ undeclared (first use in this function) ../../parser/../mem/../atomic/atomic_x86.h:342: error: expected ‘;’ before ‘volatile’ In file included from ../../parser/../mem/../lock_ops.h:85, from ../../parser/../mem/shm_mem.h:75, from ../../parser/../ut.h:64, from ../../parser/../ip_addr.h:50, from ../../parser/msg_parser.h:61, from ../../sr_module.h:62, from ndb_redis_mod.c:32: ../../parser/../mem/../futexlock.h: In function ‘futex_get’: ../../parser/../mem/../futexlock.h:110: warning: implicit declaration of function ‘syscall’ ndb_redis_mod.c: At top level: ../../parser/parse_param.h:156: warning: inline function ‘parse_param’ declared but never defined make: *** [ndb_redis_mod.o] Error 1 --- There are two separate problems here: 1) My invocation of 'make' above may betray an insufficient understanding the Makefile chain & build process. Is there something I'm doing wrong there? 2) In choosing to work around the issue this way, hiredis has imposed the requirement on GNU C users to compile any applications utilising hiredis with C99 themselves. This doesn't seem like a good solution. Is there a more 'elegant' fix here? It seems to me they ought to rename that 'unix' struct member. The blame-worthy hiredis commit seems to be this one: --- commit d9e0b0f6abfbb8918f73607bdfcc707d0df3fd41 Author: Jan-Erik Rediger <janerik(a)fnordig.de> Date: Thu Apr 16 19:28:12 2015 +0200 Implement a reconnect method for the client context Originally implemented by @abedra as part of #306. In case a write or read times out, we force an error state, because we can't guarantuee that the next read will get the right data. Instead we need to reconnect to have a clean-state connection, which is now easily possible with this method. i.e. /* Context for a connection to Redis */ typedef struct redisContext { int err; /* Error flags, 0 when there is no error */ @@ -136,6 +141,20 @@ typedef struct redisContext { int flags; char *obuf; /* Write buffer */ redisReader *reader; /* Protocol reader */ + + enum redisConnectionType connection_type; + struct timeval *timeout; + + struct { + char *host; + char *source_addr; + int port; + } tcp; + + struct { + char *path; + } unix; + } redisContext; --- Reverting to the parent commit, b872919463fbc04c3a8fde113cb9ae89dfcb3859, seems to fix the problem. That's my workaround for now. Thanks! -- Alex [1] Around 16 Apr 2015. -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

2 3

usrloc DB startup problem
by Alex Balashov 03 May '15

03 May '15

Just as a matter of passing interest: This problem appears to have reared its head again with Kamailio 4.2: http://sip-router.org/tracker/index.php?do=details&task_id=178 In my case, it is only under CentOS 7, with Kamailio running using LSB init scripts adapted through systemd. I have not seen it in any other scenario, with identical config. May 03 16:15:14 proxy /usr/local/sbin/kamailio[8508]: ERROR: db_postgres [km_pg_con.c:86]: db_postgres_new_connection(): connection pointer is NULL May 03 16:15:14 proxy /usr/local/sbin/kamailio[8508]: ERROR: db_postgres [km_pg_con.c:99]: db_postgres_new_connection(): cleaning up 0x7fef39cc9068=pkg_free() May 03 16:15:14 proxy /usr/local/sbin/kamailio[8508]: ERROR: <core> [db.c:322]: db_do_init2(): could not add connection to the pool May 03 16:15:14 csrp1 /usr/local/sbin/kamailio[8508]: ERROR: usrloc [ul_mod.c:429]: child_init(): child(0): failed to connect to database May 03 16:15:14 proxy /usr/local/sbin/kamailio[8508]: ERROR: <core> [sr_module.c:923]: init_mod_child(): Error while initializing module usrloc (/usr/local/lib64/kamaili May 03 16:15:14 proxy /usr/local/sbin/kamailio[8508]: ERROR: <core> [main.c:1707]: main_loop(): error in init_child This problem does not present when running with fork=no, and is indeed due to my loading 'usrloc' before 'db_postgres'. Swapping the loading order fixed the problem. -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

1 0

Crash in debugger module on shutdown
by Waite, Hugh 01 May '15

01 May '15

Hi, I am seeing a crash in the debugger module. It looks similar to http://sip-router.org/tracker/index.php?do=details&task_id=423 but is reproducible on shutdown. I am running latest 4.2.4. It looks like the 'get_debug_level' function is called after the debugger module has been destroyed. Do we need to unset the per-module callback from the mod_destroy function (e.g. with set_module_debug_level_cb(NULL))? Details of crash: loadmodule "debugger.so" # ----- debugger params ----- modparam("debugger", "mod_level_mode", 1) modparam("debugger", "mod_hash_size", 5) (gdb) bt full #0 0x00007f24e9572990 in dbg_get_mod_debug_level (mname=0x6f9974 "core", mnlen=4, mlevel=0x7fffe76051ac) at debugger_api.c:1224 idx = 14 hid = 1863578990 it = 0x0 #1 0x000000000046dd00 in get_debug_level (mname=0x6f9974 "core", mnlen=4) at dprint.c:137 mlevel = 3 #2 0x000000000049f6f0 in handle_sigs () at main.c:803 chld = -1 chld_status = 0 memlog = -748755048 __FUNCTION__ = "handle_sigs" #3 0x00000000004a6fbf in main_loop () at main.c:1757 i = 4 pid = 20691 si = 0x0 si_desc = "udp receiver child=3 sock=10.62.18.63:5060\000\000\000\000\000\000\016\b\000\000\377\177\000\000\260\344^\323$\177\000\000\000\000\000\020\004\000\000\000\260\344^\323$\177\000\000\060SA\000\000\000\000\000\000W`\347\001\000\000\000\220T`\347\377\177\000\000>dN\000\000\000\000\000\210q(\352z\000\000\000~~p\000\000\000\000" nrprocs = 4 __FUNCTION__ = "main_loop" #4 0x00000000004ab8e3 in main (argc=13, argv=0x7fffe7605708) at main.c:2581 cfg_stream = 0xc56010 c = -1 r = 0 tmp = 0x7fffe7605f64 "" tmp_len = 0 port = 0 proto = 32767 options = 0x6fccc0 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:" ret = -1 seed = 1220709785 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0xbf p = 0x7fffe76055de "" __FUNCTION__ = "main" (gdb) list 1219 * - use fprintf(stderr, ...) if need for troubleshooting 1220 * - it will loop otherwise */ 1221 if(_dbg_mod_table==NULL) 1222 return -1; 1223 1224 if(cfg_get(dbg, dbg_cfg, mod_level_mode)==0) 1225 return -1; 1226 1227 if(_dbg_get_mod_debug_level!=0) 1228 return -1; (gdb) p dbg_cfg $1 = (void *) 0x7f24d386298c (gdb) p *(struct cfg_group_dbg*)dbg_cfg Cannot access memory at address 0x7f24d386298c ________________________________ This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev May 2015