multistreamで送信専用で長時間配信しているとSegmentation faultで落ちる about momo

[tetsu-koba]

segv3.zip
hung1.zip
hung2.zip
ログを追加します。
hung1, hung2 はSEGVは発生しないのですが、映像音声がテレビ会議の相手側に出なくなってしまったのでmomoをkillしたケースです。
共通しているのは、Received non-DTLS packet before DTLS complete. が連発していることです。
momoは momo-19.12.0_raspbian-buster_armv7です。
いずれの場合もsora側のログにはエラーは出ていませんでした。

再現しやすい手順ですが、
momoを上記のコマンドラインオプションで起動した後に、テレビ会議に他に誰も参加しない状態で、10時間程度待ってから会議に参加、退出をすると発生します。
定期的に会議に参加、退出があると発生しないようです。

[tetsu-koba]

momo-19.12.1_raspbian-buster_armv7 でも発生しました。
segvで落ちないけど、Received non-DTLS packet before DTLS complete. が連発して使用不能な状態になるパターンです。
起動から全てのログが nohup.out に入っています。
hung3.zip

[torikizi]

原因切り分けのためにJetson Nanoとラズパイ4でロングランを実施しました。

まとめ

上記再現にある「10時間程度待ってから会議に参加、退出」の再現方法としてSoraで別端末のブラウザ経由で映像を確認、停止を実施しましたが再現することはありませんでした。
また、CPU、メモリ平均値は安定して稼働しており、ラズパイ2B環境に原因があるのではないかと考えられます。

実行結果

• Jetson Nano、ラズパイ4ともに再現せず
• 1時間ごとの平均をもとに作成したCPUとメモリの使用率

  • Jetson Nano
    

  • ラズパイ4
    

確認方法

• WindowsのChromeからSora経由で映像を確認(毎日朝と夜に再生・停止を2回ずつ)
• TOPコマンドでメモリとCPUを取得

実行コマンド

./momo --no-audio --port 0 --log-level 4 --resolution HD --framerate 20 sora --role sendonly --auto --video-codec H264 --video-bitrate 2500 --audio-codec OPUS wss://example.com/signaling xxxx@xxxx --multistream

実行環境

• momo
  自前バイナリ(12/31最新版使用)

• Jetson Nano
  Jetpack 4.3 [L4T 32.3.1]

• ラズパイ4
  Raspbian GNU/Linux 10 (buster)

[tetsu-koba]

こちらでもJetson nano でやってみますね。

[tetsu-koba]

jetson nano で試しました。SEGVで落ちるのでなくmomoは生きているけどDTLSのエラー多発で通信できない状態になりました。2回試して2回とも同様の結果になりました。
使用したのは提供バイナリの以下のものです。
momo-19.12.1_ubuntu-18.04_armv8_jetson_nano
jetson nanoの環境は
Jetpack 4.3 [L4T 32.3.1]

audio の有無は無関係のようです。
jetson_nano_hung1 の方は AUDIO_OPT='--disable-echo-cancellation --disable-auto-gain-control --disable-noise-suppression --disable-highpass-filter --disable-typing-detection'
jetson_nano_hung2の方は AUDIO_OPT='--no-audio'

./momo $AUDIO_OPT --log-level 1 --resolution QVGA --framerate 20 sora --auto --video-codec H264 --video-bitrate 1000 --audio-codec OPUS $SIGNALING_URL $CHANNEL_ID --multistream --role sendonly

ログファイルがそれぞれ27MB, 29MBなのですが、10MBより大きいファイルは添付できなくなったようで、エラーで添付できません。orz

[voluntas]

@tetsu-koba issue ありがとうございます。こちらロングランしつつ原因を探してみます。マルチストリーム系ということで、何かありそうです。

[voluntas]

@tetsu-koba 送信しっぱなしと、途中で multitream 参加すると落ちる問題は切り分けて対応していこうかと思っています。まずはロングランにお付き合いいただければと思います。

[tetsu-koba]

jetson_nano_hung1a.zip
jetson_nano_hung2a.zip

仕方がないので、起動から全部のログは外して、webrtc_log_* だけ添付しました。

[voluntas]

@tetsu-koba 7 日間配信した検証では、最後に配信は問題なくできていたようです。といっても途中で切断して再接続が走っていたという可能性はあります。

DTLSのエラー多発で通信できない状態になりました

DTLS の処理は接続時にしか行わないので、もしかすると再接続時になにかうまく動かないタイミングがあるのかもしれません。

Sora 側で「接続時間」を見てもらうことは可能でしょうか。再接続が走ってるかどうかが知りたいです。

[voluntas]

@tetsu-koba 頂いたログを確認させていただいただところ、やはり再接続で失敗しているようでした。

おそらく再接続のタイミングで問題が起きやすいのかもしれないです。こちらでは「再接続を積極的にやる」という検証をロングランでやってみようと思います。

[t2koba]

すみません。コメントいただいていたのを気がついてませんでした。

再現しやすい手順ですが、
momoを上記のコマンドラインオプションで起動した後に、テレビ会議に他に誰も参加しない状態で、10時間程度待ってから会議に参加、退出をすると発生します。
定期的に会議に参加、退出があると発生しないようです。

jetson nano では20時間待ってから別のブラウザから会議に参加して退出すると発生しました。2回試して2回とも発生しました。長時間放置しておくことがポイントのようです。

何かのカウンターが桁溢れを起こしてしまっているのかもしれません。

[voluntas]

Sora 側で「接続時間」を見てもらうことは可能でしょうか。再接続が走ってるかどうかが知りたいです。

お手数をかけて申し訳ないのですが、一度 WebSocket が切れて再接続が走っているようなので実質 20 時間繋ぎっぱなしという感じではなさそうです。再接続の頻度で実質どのくらい接続していたかがわかると助かります。

ちなみにカウンター関連で DTLS は発生することはないので、再接続時になにか問題が起きていると見ています。

[voluntas]

課題が発散気味なので、整理します。

• sora + sendonly + multistream による長時間配信で落ちる
  • @torikizi の検証により、弊社では現時点では再現しないため、クローズドとします
• 長時間つないで 別のブラウザで参加すると落ちた
  • 退出時に SDP 交換は sendonly の場合は発生しないため、別の原因がありそうです

長時間配信自体は検証したところ問題ないのですが、おそらくマルチストリームの挙動としておかしな挙動をしているという判断のため、一度こちらの issue は閉じて、別の issue を立てさせていただきます。

切り分けのためまずは sendonly -> recvonly での確認のみ行っているため、今後は sendonly と sendrecv で確認を行っていく予定です。

[voluntas]

#127 こちらに別枠として issue を立てました。長時間配信に関しては、7 日間連続で配信して、問題なかったため一旦クローズとします。