#292 segfault in xmlrpc

modules (454)

OpenSIPS 1.6.2 is segfaulting in the xmlrpc module. It seems to be corrupting some of the fields.

Backtrace #1

[New process 23293]
[New process 19097]
#0 0x080ee388 in fm_malloc (qm=0x81bfcc0, size=<value optimized out>)
at mem/f_malloc.c:172
172 *pf=n->u.nxt_free;
(gdb) backtrace
#0 0x080ee388 in fm_malloc (qm=0x81bfcc0, size=<value optimized out>)
at mem/f_malloc.c:172
#1 0x08133800 in init_mi_tree (code=200, reason=0x320eb5 "OK", reason_len=2)
at mi/tree.c:53
#2 0x003153f9 in mi_profile_list (cmd_tree=0x81f283c, param=0x0)
at dlg_profile.c:835
#3 0x007a82d2 in default_method (env=0x77fa61b4, host=0x0,
methodName=0x9f59ed0 "profile_list_dlgs", paramArray=0x9f57218,
serverInfo=0x0) at ../../mi/mi.h:104
#4 0x002cefbd in xmlrpc_dispatchCall (envP=0x77fa61b4, registryP=0x9f3af48,
methodName=0x9f59ed0 "profile_list_dlgs", paramArrayP=0x9f57218,
resultPP=0x77fa61c0) at registry.c:321
#5 0x002cf1a7 in xmlrpc_registry_process_call (envP=0x77fa6220,
registryP=0x9f3af48, host=0x0,
xml_data=0x9f587c8 "<?xml version=\"1.0\" encoding=\"UTF-8\"?><methodCall><methodName>profile_list_dlgs</methodName><params><param><value>pstn</value></param></params></methodCall>net.br</value></param></params></methodCall>"...,
xml_len=156) at registry.c:432
#6 0x002cc79b in handleXmlrpcReq (this=0x9f3c838, abyssSessionP=0x77fa6270,
handledP=0x77fa6328) at xmlrpc_server_abyss.c:382
#7 0x00360ce0 in serverFunc (userHandle=0x9f56180) at server.c:1048
#8 0x0035c7d0 in connJob (userHandle=0x9f56180) at conn.c:35
#9 0x00364592 in pthreadStart (arg=0x9f58390) at thread_pthread.c:47
---Type <return> to continue, or q <return> to quit---
#10 0x0036c73b in start_thread () from /lib/libpthread.so.0
#11 0x00acacfe in clone () from /lib/libc.so.6

The parameter net.br was never sent in the xml request (The domain is airtel.net.br)

Backtrace #2
#0 0x080ee388 in fm_malloc (qm=0x81bfcc0, size=<value optimized out>)
at mem/f_malloc.c:172
#1 0x0812f8af in add_mi_attr (node=0x81f2814, flags=<value optimized out>,
name=0x81717c8 "ID", name_len=2, value=0x81bfc9c "0", value_len=1)
at mi/attr.c:78
#2 0x08132c67 in mi_ps (cmd=0x0, param=0x0) at mi/mi_core.c:252
#3 0x0022d2d2 in default_method (env=0x77f1f1b4, host=0x0,
methodName=0x860bb40 "ps", paramArray=0x860c7b8, serverInfo=0x0)
at ../../mi/mi.h:104
#4 0x00f15fbd in xmlrpc_dispatchCall (envP=0x77f1f1b4, registryP=0x85ed8a8,
methodName=0x860bb40 "ps", paramArrayP=0x860c7b8, resultPP=0x77f1f1c0)
at registry.c:321
#5 0x00f161a7 in xmlrpc_registry_process_call (envP=0x77f1f220,
registryP=0x85ed8a8, host=0x0,
xml_data=0x860d750 "<?xml version=\"1.0\" encoding=\"UTF-8\"?><methodCall><methodName>ps</methodName><params/></methodCall>dName><params/></methodCall>\betho9", xml_len=99) at registry.c:432
#6 0x0074b79b in handleXmlrpcReq (this=0x85eec40, abyssSessionP=0x77f1f270,
handledP=0x77f1f328) at xmlrpc_server_abyss.c:382
#7 0x0023ace0 in serverFunc (userHandle=0x860a7d0) at server.c:1048
#8 0x002367d0 in connJob (userHandle=0x860a7d0) at conn.c:35
#9 0x0023e592 in pthreadStart (arg=0x86084a0) at thread_pthread.c:47
#10 0x00b4c73b in start_thread () from /lib/libpthread.so.0

In the backtrace #2 the parameter betho9 was never sent with the command but appeared in the log. This is something that call my attention.


  • Bogdan-Andrei Iancu

    Hi Flavio,

    I suspect it is related to the way the libxmlrpc-c3 lib was compiled (like having threading support instead of forking/processes support) -> this may lead to concurrent unprotected access to memory data.

    Did you installed the xmlrpc lib from packages or did you compiled by yourself ?


  • Bogdan-Andrei Iancu

    • assigned_to: nobody --> bogdan_iancu
    • status: open --> open-invalid
  • Nobody/Anonymous

    Hi Bogdan,

    I have compiled by myself. The OS is CentOS and and there is no xmlrpc package available. I have updated the system to the latest SVN and fixed a record in the drouting table. I haven't seen the problem anymore, but I'm still monitoring.

  • Bogdan-Andrei Iancu

    It has nothing to do with DB or Drouting......If you compile by yourself the lib, at configure time you need to pass an option like --disable-threading ...if I remember correctly...

    Otherwise the thread support will be compiled in.


  • Bogdan-Andrei Iancu

    • status: open-invalid --> closed-invalid

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks