Kurento server is dying with "Segmentation fault"

[Ghanshyam Agrawal]

Following logs in error log 

Segmentation fault (thread 140151982487296, pid 1571)

Stack trace:

[SSLv3_client_method]

/lib/x86_64-linux-gnu/libssl.so.1.0.0:0x23D3E

[SSL_check_chain]

/lib/x86_64-linux-gnu/libssl.so.1.0.0:0x34307

0xCBA2 at /usr/lib/x86_64-linux-gnu/gstreamer-1.5/libgstdtls.so

0xECEC at /usr/lib/x86_64-linux-gnu/gstreamer-1.5/libgstdtls.so

0x61C1 at /usr/lib/x86_64-linux-gnu/gstreamer-1.5/libgstdtls.so

0x644A at /usr/lib/x86_64-linux-gnu/gstreamer-1.5/libgstdtls.so

[gst_flow_get_name]

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0:0x6E065

[gst_pad_push]

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0:0x75DEE

0x9550 at /usr/lib/x86_64-linux-gnu/gstreamer-1.5/libgstdtls.so

[gst_flow_get_name]

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0:0x6E065

[gst_pad_push]

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0:0x75DEE

[gst_proxy_pad_chain_default]

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0:0x5F22B

[gst_flow_get_name]

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0:0x6E065

[gst_pad_push]

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0:0x75DEE

[gst_base_src_wait_playing]

/usr/lib/x86_64-linux-gnu/libgstbase-1.5.so.0:0x2FD85

[gst_tag_setter_get_tag_merge_mode]

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0:0x9FEBE

Any suggestion 

--

Thanks,

Ghanshyam Agrawal

Contact No : +919717167192

[Ghanshyam Agrawal]

Another instance 

We are not doing anything special , load is pretty low , simple presenter viewer kind of setup. 

(kurento-media-server:1615): libnice-WARNING **: (agent.c:2156):agent_signal_component_state_change: runtime check failed: (TRANSITION (DISCONNECTED, FAILED) || TRANSITION (GATHERING, FAILED) || TRANSITION (CONNECTING, FAILED) || TRANSITION (CONNECTED, FAILED) || TRANSITION (READY, FAILED) || TRANSITION (DISCONNECTED, GATHERING) || TRANSITION (GATHERING, CONNECTING) || TRANSITION (CONNECTING, CONNECTED) || TRANSITION (CONNECTED, READY) || TRANSITION (READY, CONNECTED) || TRANSITION (FAILED, CONNECTING) || TRANSITION (DISCONNECTED, CONNECTING)|| TRANSITION (CONNECTING, GATHERING))

Segmentation fault (thread 140501650921216, pid 1615)

[Ghanshyam Agrawal]

Any suggestions please , 

Now servers are dying a lot 

Segmentation fault (thread 140456419645184, pid 1652)

[t.vand...@sping.nl]

We're facing the same issue on our servers. Did you manage to find any solution to this?

Our stack trace:

^[[31;1mSegmentation fault^[[0m (thread ^[[33;1m140375925704448^[[0m, pid ^[[33;1m25481^[[0m)

Stack trace:

^[[34;1m[SSLv3_client_method]^[[0m

/lib/x86_64-linux-gnu/libssl.so.1.0.0^[[32;1m:0x23CFE^[[0m

^[[34;1m[SSL_check_chain]^[[0m

/lib/x86_64-linux-gnu/libssl.so.1.0.0^[[32;1m:0x34237^[[0m

^[[32;1m0xC9CE^[[0m at /usr/lib/x86_64-linux-gnu/gstreamer-1.5/libgstdtls.so

^[[32;1m0xEAB1^[[0m at /usr/lib/x86_64-linux-gnu/gstreamer-1.5/libgstdtls.so

^[[32;1m0x6162^[[0m at /usr/lib/x86_64-linux-gnu/gstreamer-1.5/libgstdtls.so

^[[32;1m0x63FA^[[0m at /usr/lib/x86_64-linux-gnu/gstreamer-1.5/libgstdtls.so

^[[34;1m[gst_flow_get_name]^[[0m

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0^[[32;1m:0x6E6FF^[[0m

^[[34;1m[gst_pad_push]^[[0m

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0^[[32;1m:0x76663^[[0m

^[[32;1m0x94CC^[[0m at /usr/lib/x86_64-linux-gnu/gstreamer-1.5/libgstdtls.so

^[[34;1m[gst_flow_get_name]^[[0m

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0^[[32;1m:0x6E6FF^[[0m

^[[34;1m[gst_pad_push]^[[0m

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0^[[32;1m:0x76663^[[0m

^[[34;1m[gst_proxy_pad_chain_default]^[[0m

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0^[[32;1m:0x5F5E3^[[0m

^[[34;1m[gst_flow_get_name]^[[0m

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0^[[32;1m:0x6E6FF^[[0m

^[[34;1m[gst_pad_push]^[[0m

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0^[[32;1m:0x76663^[[0m

^[[34;1m[gst_base_src_wait_playing]^[[0m

/usr/lib/x86_64-linux-gnu/libgstbase-1.5.so.0^[[32;1m:0x30D75^[[0m

^[[34;1m[gst_tag_setter_get_tag_merge_mode]^[[0m

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0^[[32;1m:0xA0D8B^[[0m

^@

Op vrijdag 9 juni 2017 18:28:41 UTC+2 schreef Ghanshyam Agrawal:

[Ghanshyam Agrawal]

Not yet. 

What we figured out was that it was happening on some particular machines (every time on these machines). 

Though for some other reasons we didnt get machine access to debug this further. 

--
You received this message because you are subscribed to the Google Groups "kurento" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kurento+unsubscribe@googlegroups.com.
To post to this group, send email to kur...@googlegroups.com.
Visit this group at https://groups.google.com/group/kurento.
To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/fc0bc0f2-dd9a-490a-ad28-c807125d2a98%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[t.vand...@sping.nl]

Thanks for your answer! Are you saying that you have servers (machines) that have this problem frequently and other servers that don't have this issue at all?

Not sure what that would mean though. 

Best regards,

Tom

Op woensdag 5 juli 2017 08:53:36 UTC+2 schreef Ghanshyam Agrawal:

To unsubscribe from this group and stop receiving emails from it, send an email to kurento+u...@googlegroups.com.

To post to this group, send email to kur...@googlegroups.com.
Visit this group at https://groups.google.com/group/kurento.
To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/fc0bc0f2-dd9a-490a-ad28-c807125d2a98%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ghanshyam Agrawal]

No ,Not the server machine.

I meant the client machine , could be camera/browser/machine configuration issue. 

To unsubscribe from this group and stop receiving emails from it, send an email to kurento+unsubscribe@googlegroups.com.

To post to this group, send email to kur...@googlegroups.com.
Visit this group at https://groups.google.com/group/kurento.

To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/d040305f-56d0-41cc-927a-a1fc98dbea21%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[t.vand...@sping.nl]

For now I found a pattern that indicates that the segfault happens upon receiving (or sending?) the first media after successful determining a candidatePair (ICE). The crash is obviously in libssl but probably because Kurento passes some bogus value (null?)

And the other observation is that the first readable part in the stack trace is a call to SSLv3_client_method and SSLv3 should not be used anymore at all since the POODLE vulnerability in 2014. My hypothesis is that the client includes SSLv3 in its DTLS handshake and Kurento tries to call a method in libssl that does no longer exist (SSLv3 has been removed/blocked in newer distributions) or returns an error which is not handled properly.

Any ideas?

Thanks in advance,

Tom

Op woensdag 5 juli 2017 11:42:35 UTC+2 schreef Ghanshyam Agrawal:

To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/d040305f-56d0-41cc-927a-a1fc98dbea21%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[t.vand...@sping.nl]

I've found the event that leads to this crash! Network traces indicate that Kurento crashes when an error occurs in the DTLS handshake. I've captured all UDP traffic during a crash. In short the failing DTLS handshake looks like this:

S = server, C = client

S -> C Client Hello

S -> C Client Hello (retransmit after 2 sec)

C -> S Client Hello (exactly the same content as S->C messages)

S -> C Alert (Level: Fatal, Description: Unexpected Message)

C -> S Alert (Level: Fatal, Description: Unexpected Message)

*BOOM*

Now I'm going to focus on finding the cause of this crash.

Tom

Op woensdag 5 juli 2017 22:07:05 UTC+2 schreef t.vand...@sping.nl:

[Micael Gallego]

Thank you t.vandergeer.

Can you test with the KMS development version? We have fixed several crashes.

Best regards

Micael Gallego

Kurento / OpenVidu Project Lead

To unsubscribe from this group and stop receiving emails from it, send an email to kurento+unsubscribe@googlegroups.com.

To post to this group, send email to kur...@googlegroups.com.
Visit this group at https://groups.google.com/group/kurento.

To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/7c0d88f9-5b12-4bc3-86f1-0a0d320e6f0e%40googlegroups.com.

[t.vand...@sping.nl]

Hi Micael,

Thanks for your answer! I would love to test de development version. Is there any particular fix you have in mind that could solve this issue?

I will follow the instructions to "install from unstable repository" from here (and use "xenial" in stead of "trusty"). Or do you mean some other way of installing the development version?

Best regards,

Tom

Op donderdag 6 juli 2017 14:10:01 UTC+2 schreef OpenVidu:

[Micael Gallego]

You have to follow the instructions of the following page:

http://doc-kurento.readthedocs.io/en/stable/mastering/kurento_development.html

Best regards

Micael Gallego

Kurento / OpenVidu Project Lead

To unsubscribe from this group and stop receiving emails from it, send an email to kurento+unsubscribe@googlegroups.com.

To post to this group, send email to kur...@googlegroups.com.
Visit this group at https://groups.google.com/group/kurento.

To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/bc58f051-51bb-478d-983e-00039a11949d%40googlegroups.com.

[t.vand...@sping.nl]

A quick update: De development version of Kurento has been running solid over 30 hours now. I'm not sure if the conditions which led to the crashes earlier actually occurred in the last 30 hours, but so far this looks good.

But obviously this "development version" is not suited for production (it even says so on the installation page). Do you have any suggestions on how to proceed to get this to production systems?

Best regards,

Tom

Op donderdag 6 juli 2017 14:32:05 UTC+2 schreef OpenVidu:

[Micael Gallego]

We are going to publish a new release in the following days. Please stay tuned.

Best regards

Micael Gallego

Kurento / OpenVidu Project Lead

To unsubscribe from this group and stop receiving emails from it, send an email to kurento+unsubscribe@googlegroups.com.

To post to this group, send email to kur...@googlegroups.com.
Visit this group at https://groups.google.com/group/kurento.

To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/c87039d9-949e-4c8d-a429-dcfdb6395878%40googlegroups.com.

[t.vand...@sping.nl]

Thanks Micaal, however the issue has not been resolved in the development version unfortunately. It crashed last night with an identical stack trace (see below).

There's something making the server crash when the DTLS handshake fails (see earlier posts in this topic). Probably caused by packet loss or large delays. Did you test Kurento under suboptimal network conditions?

Stack trace:

^[[31;1mSegmentation fault^[[0m (thread ^[[33;1m140688668321536^[[0m, pid ^[[33;1m19592^[[0m)

Stack trace:

^[[34;1m[SSLv3_client_method]^[[0m

/lib/x86_64-linux-gnu/libssl.so.1.0.0^[[32;1m:0x23CFE^[[0m

^[[34;1m[SSL_check_chain]^[[0m

/lib/x86_64-linux-gnu/libssl.so.1.0.0^[[32;1m:0x34237^[[0m

^[[32;1m0xC9CE^[[0m at /usr/lib/x86_64-linux-gnu/gstreamer-1.5/libgstdtls.so

^[[32;1m0xEAB1^[[0m at /usr/lib/x86_64-linux-gnu/gstreamer-1.5/libgstdtls.so

^[[32;1m0x6162^[[0m at /usr/lib/x86_64-linux-gnu/gstreamer-1.5/libgstdtls.so

^[[32;1m0x63FA^[[0m at /usr/lib/x86_64-linux-gnu/gstreamer-1.5/libgstdtls.so

^[[34;1m[gst_flow_get_name]^[[0m

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0^[[32;1m:0x6E5CF^[[0m

^[[34;1m[gst_pad_push]^[[0m

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0^[[32;1m:0x76533^[[0m

^[[32;1m0x94CC^[[0m at /usr/lib/x86_64-linux-gnu/gstreamer-1.5/libgstdtls.so

^[[34;1m[gst_flow_get_name]^[[0m

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0^[[32;1m:0x6E5CF^[[0m

^[[34;1m[gst_pad_push]^[[0m

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0^[[32;1m:0x76533^[[0m

^[[34;1m[gst_proxy_pad_chain_default]^[[0m

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0^[[32;1m:0x5F5E3^[[0m

^[[34;1m[gst_flow_get_name]^[[0m

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0^[[32;1m:0x6E5CF^[[0m

^[[34;1m[gst_pad_push]^[[0m

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0^[[32;1m:0x76533^[[0m

^[[34;1m[gst_base_src_wait_playing]^[[0m

/usr/lib/x86_64-linux-gnu/libgstbase-1.5.so.0^[[32;1m:0x30D75^[[0m

^[[34;1m[gst_tag_setter_get_tag_merge_mode]^[[0m

/usr/lib/x86_64-linux-gnu/libgstreamer-1.5.so.0^[[32;1m:0xA0C5B^[[0m

Thanks for all the help,

Tom

Op zaterdag 8 juli 2017 16:09:54 UTC+2 schreef OpenVidu:

[t.vand...@sping.nl]

A quick update: I did not manage to find a solution to this issue. I think it's crucial to get this fixed before anybody ever tries to use Kurento in a production environment. I am a big fan of Kurento but this issue made me look for a solution in a different direction.

Best regards,

Tom

Op zondag 9 juli 2017 09:15:39 UTC+2 schreef t.vand...@sping.nl:

[Manoj Kumar Verma]

We are also facing the same issue and can't find any solution. We are stuck with our development using Kurento. I also posted this issue in Kurento bug tracker but did not get any response.

[Micael Gallego]

Hi guys, 

Do you have a reliable way to reproduce the crash? We will try to fix it but first we have to found a reliable way to reproduce the problem in our development environment.

Best regards

Micael Gallego

Kurento / OpenVidu Project Lead

To unsubscribe from this group and stop receiving emails from it, send an email to kurento+unsubscribe@googlegroups.com.

To post to this group, send email to kur...@googlegroups.com.
Visit this group at https://groups.google.com/group/kurento.

To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/88aea99d-72e1-4342-ac80-9ed82fa1187d%40googlegroups.com.

[t.vand...@sping.nl]

We've developed a tool that "cripples" the network traffic (introduces jitter, packet loss and introduces delay) based on tc. I'm going to give it a try to see if can reproduce the issue with this. If so I can draw up some instructions or even create a Vagrant box with all tools required to reproduce the issue. Is Vagrant something you are comfortable working with? Meanwhile the project I'm working on moved on to another technology so I might not be able to spend much time on this.

Best regards,

Tom

Op maandag 17 juli 2017 18:09:05 UTC+2 schreef OpenVidu:

[Micael Gallego]

It would be great if you can share with us a way to reproduce this issue. Vagrant is perfect for us.

For curiosity, what software are you using now? We want to compare kurento with other webrtc servers and real experiences will help to us.

Best regards

To unsubscribe from this group and stop receiving emails from it, send an email to kurento+unsubscribe@googlegroups.com.

To post to this group, send email to kur...@googlegroups.com.
Visit this group at https://groups.google.com/group/kurento.

To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/50fa3ee5-69e2-4b51-9ae4-5c3cd42ecc39%40googlegroups.com.

[t.vand...@sping.nl]

Hi Micael,

To answer your last question first; we were aiming for creating a WebRTC to SIP Gateway for Voice calls. Not a typical scenario for Kurento, but we were pretty successful until we hit the issues in production. We've now switched to using Freeswitch. It works great. It just doesn't have trickle-ICE...

Meanwhile I tried reproducing the crash. At first I attempted to cripple the network by using a custom script that introduces a lot of jitter, packet loss, packet duplication, delay, etc. No matter how much I threw in; Kurento survived. No crash. Just bad video and audio, but that's expected under these network conditions.

Then I took a closer look at the network trace I made of the call that crashed the server (I can share that trace if you like, just not publicly). In my earlier post I focussed on the DTLS handshake. That's eventually what brings Kurento to it's knees. But there are some other interesting things going on as well. My observations when I look at all (UDP) packets involved in this call:

1. It starts with a STUN binding and response sequence between the two peers (our Kurento server and the client on the other side). This is part of the process of finding an IceCandidate pair. This looks a bit messy because of delay in the network which causes retransmissions, but eventually this is successful.

2. Kurento sends a 74 byte UDP packet which looks to me like an RTCP Receiver report.

3. A few packets later Kurento sends a Client Hello to kick off a DTLS handshake.

For this point on the remote peer just echoes every packet we send out. Every packet is received exactly the same as the one we sent out. The 74-byte UDP packets (RTCP Receiver reports?) and the DTLS handshake packets. Only the sender and receiver (IP and port) are swapped. The other end is echoing our packets immediately after successful STUN binding.

So when the Client Hello we send out in step 3 is received back on our end we send out a DTLS Alert which is received 0.12 seconds later on our end again. This is when Kurento fails. It crashes with a segmentation fault.

Since we released our own WebRTC client for this service and this service is exclusively used with this client we know that the remote end is not using a crappy old non-compatible browser or such. They are using our client. And our client is not echoing UDP packets. Something else is doing that. But what? Something in the network?

Then it struck me when I looked up the location of the remote peer based on geo-ip location; it's in Oman. A country that is blocking VoIP traffic as much as it can. Could it be that, part of their VoIP blocking countermeasures, they are allowing STUN but echo every packet after that? I could not find any online reference of this theory. But then again, we don't need to know what causes this. We just need to make sure that Kurento does not crash under these circumstances. When you want to host a public available service based on Kurento, you might end up with a client from this country or at least display the same "defect". And Kurento should not crash. Period.

Now things are getting a bit more tricky. I need to build a client that does a successful STUN binding request response flow but then echoes every following packet. We need that if we want to be able to reproduce the crash. I'm fighting some deadlines at work and an upcoming holiday with my family. It's all about priorities. This issue didn't make the cut. So here I lay it all out for you. If someone is able to build this client in the coming three weeks, please do! When I'm back in 3 weeks and no one beat me to it I will do it myself.

I'd be happy to provide any more information whenever I can.

Best regards,

Tom van der Geer

Op dinsdag 18 juli 2017 20:39:42 UTC+2 schreef Micael Gallego Carrillo:

[t.vand...@sping.nl]

Yeehaa!!! A few minutes ago I was able to reproduce the crash in Kurento with my own WebRTC client that initiates a STUN binding sequence and after successful completion it echoes all received packets (see my previous post). On the Kurento side I'm running a vanilla kurento-hello-world example. The code of the client is kind of messy and it's using node 0.10.x because node-libnice - the ICE library I'm using - is not available for versions >0.10. The clients code not in a state that I'm comfortable sharing with you right now, but give me some time...

Best regards,

Tom van der Geer

Op donderdag 20 juli 2017 23:53:19 UTC+2 schreef t.vand...@sping.nl:

[t.vand...@sping.nl]

And the code is here: https://github.com/tvandergeer/dtls-handshaker

See instructions in the readme

Best regards,

Tom van der Geer

Op vrijdag 21 juli 2017 23:57:45 UTC+2 schreef t.vand...@sping.nl:

[t.vand...@sping.nl]

Hi Micael,

Can you pleas confirm that you've seen my post with a client that reliably reproduces the crash? You can find the code here: https://github.com/tvandergeer/dtls-handshaker/

When you've got Vagrant on your system and you have an instance of the hello-world example up and running somewhere, you can perform a test in under 5 minutes.

In my opinion this crash needs to be fixed before anybody can use Kurento in a production environment for a public application using WebRTC. The risk of anybody connecting from a country that has similar VoIP blocking technologies in place is too high.

[Micael Gallego]

Hi Tom,

We are aware of your application that reproduce the crash in Kurento. Thank you very much for your effort.

We are very bussy with other issues in KMS. When we finish this other work, we'll take a look to your issue.

Best regards

--
You received this message because you are subscribed to the Google Groups "kurento" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kurento+unsubscribe@googlegroups.com.
To post to this group, send email to kur...@googlegroups.com.
Visit this group at https://groups.google.com/group/kurento.

To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/0cb750cc-ef57-4bca-ac59-25490d99c85b%40googlegroups.com.

[Ghanshyam Agrawal]

Hi Micale,

I just wanted to add few points on Tom's view. We are also using kurento on our production systems (since one year without much trouble) 

But our current state is that we had to restart kurento 10-15 times daily because of this issue( practically we are not able to use kurento anymore and looking for some other options).

We also noticed that this happens when data is coming from Dubai/Oman countries. and some how this started happening since last 2 months

This issue is very very critical for us (and for anyone who usages kurento on production system). 

Hoping you will increase the priority of this issue (and now you have reproducer too. ) 

To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/CAFXW_DtoBPJhHA2OQvOfwSh9icq8%2BQjE1aDNneKfD3Hkrk1sHA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Micael Gallego]

Hi Ghanshyam,

We are very sorry that you have problems with Kurento in production. We are now a small team and we dont have enough resources to fix all issues. 

Remember that we are open to external contributions and PRs. Also, you can fund the team to work on an specific issue.

Best regards.

To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/CAKrA8GOnMn_sewQx71dNUfAe4NPHUaf6-ocofh7Z-hiAR06GqQ%40mail.gmail.com.

[Ankit Gupta]

Hi Micael,

We are using kurento in our development and testing servers since a few months but never found any critical issue.

But as soon as we started using it on the production server where receivers are in gulf countries(Oman, riyadh etc), kurento crashed every time we tried to use it.

This is a very critical issue and should be fixed before anyone uses it on production server.

Kurento version:

Module: 'core' version '6.6.1'

Module: 'elements' version '6.6.1'

Module: 'filters' version '6.6.1'

Best regards.

To unsubscribe from this group and stop receiving emails from it, send an email to kurento+u...@googlegroups.com.

To post to this group, send email to kur...@googlegroups.com.
Visit this group at https://groups.google.com/group/kurento.

To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/0cb750cc-ef57-4bca-ac59-25490d99c85b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "kurento" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kurento+u...@googlegroups.com.

To post to this group, send email to kur...@googlegroups.com.
Visit this group at https://groups.google.com/group/kurento.

To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/CAFXW_DtoBPJhHA2OQvOfwSh9icq8%2BQjE1aDNneKfD3Hkrk1sHA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Thanks,

Ghanshyam Agrawal

Contact No : +919717167192

--
You received this message because you are subscribed to the Google Groups "kurento" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kurento+u...@googlegroups.com.

To post to this group, send email to kur...@googlegroups.com.
Visit this group at https://groups.google.com/group/kurento.

[Chandrashekhar Singh]

Please check the logs where "Segmentation Fault" coming multiple times and kurento media server stopped.

[t.vand...@sping.nl]

Hello Chandrashekhar,

Yes, this looks like you're having the same issue.

The Kurento team is aware of it and will work on a solution when they've finished some other issues.

Best regards,

Tom

[Chandrashekhar Singh]

Hello Tom,

Your team is doing really good in the Kurento.

Is there any approximate timeline?

We integrated this kurento with our application and this is very crucial for us.

--
You received this message because you are subscribed to a topic in the Google Groups "kurento" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kurento/AJdjdJvFmyg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to kurento+unsubscribe@googlegroups.com.

To post to this group, send email to kur...@googlegroups.com.
Visit this group at https://groups.google.com/group/kurento.

To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/42dc38d1-980b-41e9-8101-a27e931d6844%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Thanks & Regards
Chandra Shekher Singh
Project Manager

[t.vand...@sping.nl]

Hello Chandrashekhar,

I'm not part of the Kurento team so I can't answer your question on the timeline. I'm sure the team will do everything it can to resolve this issue asap.

The company I work for had (past tense) a Kurento based application which suffered from the same issue. We switched to other technology because we didn't have the time to get to the bottom of it. Since I'm personally a big fan of Kurento I've spent some personal time on this issue and that's when I found a way to reproduce the situation.

[Juan Navarro]

For people interested in this issue, you can track it here: https://github.com/Kurento/bugtracker/issues/242

[t.vand...@sping.nl]

Great to see this issue got some attention!

Thanks,

Tom

Op zaterdag 7 april 2018 23:49:42 UTC+2 schreef Juan Navarro: