Hi,
that's in fact very strange: Emil's fix is already in 1.4...
On 30.03.11 23:09, Emil Kroymann wrote:
Hi,
this could be the issue I reported in semsdev list. The XMLRPC
server uses select which corrupts the stack if the entered socket
fd number is larger than 1024, i.e. if SEMS overall has more than
1024 open files and sockets.
As a solution, the XMLRPC server has to be patched to use poll()
instead of select().
Regards,
Emil
Am Wed, 30 Mar 2011 11:50:05 -0700 (PDT)
schrieb B Kaser<[email protected]>:
Hello,
We are developing a conferencing application on SEMS 1.4.0. It is
generally very stable, but under load I am getting a core dump in
xmlrpc2di when periodically entering commands, in this case calls().
I have seen the same thing on 1.3. Is it possible this WorkerThread
instance is getting deleted? Thanks.
Could you please describe us the steps to reproduce the issue a little
bit more?
-Raphael.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x4083a940 (LWP 9695)]
XmlRpc::XmlRpcDispatch::work (this=0x20, timeout=-1) at
src/XmlRpcDispatch.cpp:95
95 if (_doClear)
(gdb) where
#0 XmlRpc::XmlRpcDispatch::work (this=0x20, timeout=-1) at
src/XmlRpcDispatch.cpp:95
#1 0x00002b0e1c4cfc1f in XmlRpc::WorkerThread::run (this=0xaae2c80)
at MultithreadXmlRpcServer.cpp:34
#2 0x00000000004d0f16 in AmThread::_start (_t=<value optimized out>)
at AmThread.cpp:70
#3 0x00000035162064a7 in start_thread () from /lib64/libpthread.so.0
#4 0x00000035156d3c2d in clone () from /lib64/libc.so.6
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems