Yate server > Yate bugs

Picking up an endpoind from peer of extmodule crashes Yate

(1/3) > >>

andr04:
I'm trying to fix the bug during last days, but without success. :(

If I have a sip endpoint which is connected to an external plugin (in playrec mode) a try to picking it up (disconnect extmodule and connect sip endpoints each other) crashes Yate at all in 90% of cases.

The log which I see:

--- Code: ---2017-05-01_23:17:24.413847 <INFO> Choosing offered 'audio' format 'alaw' [0x7fb840011bc0]
2017-05-01_23:17:24.413857 <sip/3:NOTE> Formats for 'audio' changed to 'alaw' [0x7fb840010990]
2017-05-01_23:17:24.413902 >>> DataTranslator::detachChain(0x7fb83c006dd0,0x7fb84c00fac0)
2017-05-01_23:17:27.000093   <engine:MILD> Creating new message dispatching thread (1 running)
2017-05-01_23:17:29.000097   <engine:MILD> Creating new message dispatching thread (2 running)
...
--- End code ---

The normal state (if I disconnecting tone endpoint):

--- Code: ---2017-05-01_22:36:17.464148 <yrtp:INFO> RTP starting format 'alaw' payload 8 [0x7fb840016b40]
2017-05-01_22:36:17.464172 >>> DataTranslator::detachChain(0x7fb840017190,0x7fb8300040a0)
2017-05-01_22:36:17.464177 <<< DataTranslator::detachChain
2017-05-01_22:36:17.464185 <ALL> DataTranslator::attachChain [0x7fb840017190] 'alaw' -> [0x7fb8300040a0] 'alaw' succeeded
2017-05-01_22:36:17.464190 >>> DataTranslator::detachChain(0x7fb830003ec0,0x7fb840017320)
2017-05-01_22:36:17.464193 <<< DataTranslator::detachChain
2017-05-01_22:36:17.464198 <ALL> DataTranslator::attachChain [0x7fb830003ec0] 'alaw' -> [0x7fb840017320] 'alaw' succeeded
2017-05-01_22:36:17.464270 <yrtp:INFO> Wrapper opened a hole in firewall/NAT [0x7fb840016b40]
--- End code ---

marian:
Hi,
Can you provide a larger log?
A backtrace would help a lot.
You may start yate with -C command line option.
Please see http://docs.yate.ro/wiki/Bug_reporting on how to build a backtrace.

andr04:
See attachments (suppose it doesn't contain a private data; if no notify me please). It's not a crash in true understanding but it produces extra threads without success and after that (if run Yate as a service) it restarted by supervisor process. Without a supervisor process it hangs up.

Log contains some extra test outputs (from extmodule.cpp and external modules as well).

The scenario was:
1. Call from 'home' to 'mobile'.
2. Hangup 'home' leg => 'mobile' leg connects to 'noise.py' (it's a channel module).
3. Call from 'home' to 'mobile' again => not happy to picking up 'mobile' leg from 'noise.py'.
4. Since not happy hangup 'home' and 'mobile'.

To manage the call logic I use 'monitor.py' (it's a global module). I believe the external modules ('monitor.py' and 'noise.py') is correct because if 'monitor.py' runs 'call.execute' with 'callto'='tone/milliwatt' (instead of 'external/playrec/noise.py') no any bugs are happend.

Also it seems external modules don't killed in a proper way. For example on restarting external module I see the following:

--- Code: ---2017-05-02_08:36:57.353068 <TEST> !!! ExtModReceiver::die
2017-05-02_08:36:57.353114 <ALL> ExtModReceiver::die() pid=10175 dead=no [0x191e4f0]
Unloading external module 'monitor.py' ''
2017-05-02_08:36:57.353130 <ALL> ExtModReceiver::die() waiting for pid=10175 to die [0x191e4f0]
2017-05-02_08:36:57.360740 <INFO> ExtModReceiver::die() pid=10175 did not exit? [0x191e4f0]
2017-05-02_08:36:57.360768 <TEST> !!! ExtModReceiver::flush
2017-05-02_08:36:57.361942 <TEST> !!! ExtModReceiver::cleanup
2017-05-02_08:36:57.361999 <WARN> Process 10175 has not exited on closing stdin - we'll kill it
2017-05-02_08:36:57.362118 <WARN> Process 10175 has still not exited yet?
2017-05-02_08:36:57.365940 <ALL> ExtModReceiver::destruct() pid=0 [0x191e4f0]
2017-05-02_08:36:57.365961 <TEST> !!! ExtModReceiver::die
2017-05-02_08:36:57.365966 <ALL> ExtModReceiver::die() pid=0 dead=yes [0x191e4f0]
2017-05-02_08:36:57.366000 <ALL> ExtModReceiver::ExtModReceiver("monitor.py","(null)") [0x7f36840010f0]
Loading external module 'monitor.py' ''
--- End code ---

'monitor.py' handles stdin and sigint in a proper way. I don't understand in the code why we killing external (call closeOut) in 2 places: in ExtModReceiver::die and ExtModReceiver::cleanup . And in both cases we don't wait for a reasonable time (because an external module can be complicated and requires a time for proper terminating). Another question is why we don't kill by sigint signal (sigterm only in a last chance)? Since we terminate in 2 different places I don't know for sure how to fix it in a proper way as well.

marian:
What version of yate svn are you using?
Did you made any other changes (except for debug messages) in extmodule?

andr04:
Yes, I've make some changes.

First, I use release version. When I haven't reach a success I replaced extmodule.cpp from trunk. Then I add ability to use CallEndpoint by extmodules which are started by the global one: it's only one line of new code ExtModReceiver::processLine:
--- Code: ---     if (m_setdata) {
CallEndpoint* c_chan = locateChan(m->getValue("channelid"),m->getBoolValue("channelid_peer"));
m->userData(c_chan ? c_chan : m_chan);
            }
--- End code ---
After that I started to solve the described bug and tried to add to ExtModSource methods cleanup and attached (from wavefile.cpp) - it also doesn't help.

My latest version of extmodule.cpp is attached.

Navigation

[0] Message Index

[#] Next page