接触通知アプリCOCOAの不具合、Xamarinを使用したことが一因か？ 204
合理的にやろうとしたけれど 部門より
Android版で接触通知が行われないという致命的なバグのあった「接触通知アプリCOCOA」だが、iPhoneにも使用日数が数日毎にリセットされるといった致命的な不具合が複数報告されている（Togetter）。yprestoさんのツイートによると、
COCOA iOSが初期化されるバグ、Xamarin.Formsがファイルを削除→移動している箇所でbreakpointで止めて、そのままアプリを落とすと、確かに初期化されることを確認しました（Githabへの書き込み）
とのこと。タレコミ元のTogetterまとめにあるようにXamarin自体にバグがあったかどうかかは別として、発注や運用に問題があったといわれても仕方ない状況ではあるようだ。
あるAnonymous Coward 曰く、
Android版に致命的な不具合があったことが判明したCOCOA、iPhoneにも致命的な不具合が生じているとの報告が多く、平井卓也デジタル改革担当相もiPhoneでも起きている可能性について十分あると記者会見で述べたが、最近になってその原因の可能性として、COCOAの実装に使われているマルチプラットフォーム化中間フレームワーク「Xamarin」のコアにレースコンディションのバグがあることが発見された。まとめ「COCOA iPhone版のリセット不具合 Xamarinの基礎的欠陥が発見される」によると、設定情報を保存したプロパティをシリアライズしてファイルに書き出すロジックで、「.tmp」に書き出したのちに、元のファイルを削除してから、「.tmp」を元のファイル名にリネームすするコードが書かれているという。そのため、削除してリネームするまでの間に、プロセスがOSにより強制終了されると、設定ファイルが消失し、アプリが初期化されてしまうという。
こんなのレアケースやんけ (スコア:2)
通報が届いてなかったとかに比べりゃどってことなくね?
Re:こんなのレアケースやんけ (スコア:2)
そうなのか…なんてそんな起きるんだろうこんなの
削除してリネームの間に落とされるとか…
普通のOSではあまり起きず、モバイルOSで起きやすい現象なんかね?
プラットフォームにあったらかなり恥ずかしい問題ではあるけど
まだ他にも問題あるってだけかも
保存回数がべらぼうに多くてやたら踏みやすくなってるって可能性もあるか
Re:こんなのレアケースやんけ (スコア:1)
>普通のOSではあまり起きず、モバイルOSで起きやすい現象なんかね?
>プラットフォームにあったらかなり恥ずかしい問題ではあるけど
モバイルOS用のアプリ設計で一番初めに習う部類の話だったりします
AndroidのLow Memory Killerとか調べてみてくださ
Xamarinの該当コード部分（iOS版）をざっと読んでみた感じ、
・プロセスが殺されるタイミングによって書き出しファイルが無くなる実装（tmpファイルとしては残る）
・読み込み時にはtmpファイルを見ない（tmpファイルに一旦書き出すのは書き出し時の都合）
アプリ側でも対策出来ますが、読み込み時にtmpをチェックするようにするのが良さそう
>保存回数がべらぼうに多くてやたら踏みやすくなってるって可能性もあるか
なお、まとめよりの伝聞となり不確かではありますが、以下理由でiOSで発生しやすい可能性が考えられるそうです
・iOS版のCOCOAはバックグラウンド起動6回/日（Android版は1回/日？）
・iOSでのバックグランドのユーザプロセスは、タイムアウトなどでも殺される（Androidはメモリが余っていれば殺されない？）
Android版はバックグラウンドでのデータ取得に失敗する不具合がありますが
その場合は設定ファイルの保存までたどり着けないとか
Re:こんなのレアケースやんけ (スコア:2)
まずXamarinにそういうバグがあったのが何でなのかなーと
モバイルOSの特性だとしてiOS版のXamarinはそういうの知らん人が書いたんですかね?
元々あった別OS用のを見ながら書いた、とかなんかなぁ
使うほうとしては「Xamainの添付ファイル保存が腐ってる」とかそんなレベルの前提置いたら何も使えなくなりそう
MemoryKillerとかも知ってはいるんですがどれだけの頻度で実際起きるのか
しかもタイミングシビアそうじゃないですかコレ
そんなに都合よく衝突するもんかな?って感じします
これ「も」あるんだろうけどほかにもあるんじゃねって
Re:こんなのレアケースやんけ (スコア:1)
＃昨日のニュースだと新版も問題あったとか…
>モバイルOSの特性だとしてiOS版のXamarinはそういうの知らん人が書いたんですかね?
>元々あった別OS用のを見ながら書いた、とかなんかなぁ
https://t.co/NxFSijGXr7 [t.co]
このコードを見る限りはiOS対応で人が手を入れたのか疑問です
macOS版に定型のdefineを機械的に埋め込んで取りあえずビルド出来るようにした、という感じにも…
>しかもタイミングシビアそうじゃないですかコレ
>そんなに都合よく衝突するもんかな?って感じします
実際の発生頻度がわからないのであれですが、基本的な認識を疑ってみる必要も有りますね
妄想の域ですが、
・実は削除やリネームの完了には思った以上に時間がかかるときが有る
→デバイス、ドライバの都合、ウィルススキャナ等の暗躍など
・実は思った以上に殺される
→COCOAがリソース食い
→バックグラウンドが実は正時起動とかなっていて、正時起動の他のアプリが多数ある
タイミング問題は、時として予想外のタイミング同期ポイントとかが有ったりして予想通りの発生頻度にならないこともしばしばかと（都合よく発生）
今回はAndroid版の不具合なんかの報道で注目度が上がっていましたので
バックグラウンド起動あたりの不具合発生確率が1ppmもあれば十分発覚するかと
フレームワークにバグが見つかると、発注や運用の問題？ (スコア:0)
かなり謎な理論に感じますが・・・
Re: (スコア:0)
フレームワークにバグがあること自体は発注や運用の責任ではないが、アプリ利用中にフレームワークが誤動作することのを気がつかずに何ヶ月も配布していたのは明らかに発注や運用の責任だろう。
Re: (スコア:0)
マジレスを期待されてないかもだが・・・
このレベルの不具合を検知する手当すら打ってなかったの?
ってことかと
(現場というより上位層の手抜きの問題)
Re: (スコア:0)
いまの発注運用体制なら、どのフレームワーク（あるいはネイティブ）を使っても似たような状況になっていただろう
Re: (スコア:0)
＞もしネイティブで作ってれば各OSの更新を見ていればよくて、ミドルウェアに付き合う必要はない。
＞ここまでが前提。
デマだらけで草
Re: (スコア:0)
ネイティブで作ってミドルウェア使わないなら、ミドルウェア考えなくていいのはそのとおりでは？
Re: (スコア:0)
ネイティブコード実行させてくれるモバイルOSってあるんですかね
Re: (スコア:0)
ネイティブで作ってれば、ミドルウェアに付き合う必要はない。←あきらかな嘘
ミドルウェア使わないなら、ミドルウェアに付き合う必要はない。←小泉回文
ネイティブに関係なく、ミドルウェア使うなら（使わないなら）ミドルウェアに付き合う必要がある（必要がない）。←前提に関係ないとバレる
Xamarin自体にバグがあったかどうかかは別として (スコア:0)
何が別としてなの？
エンバグするというのは、ソフト開発では普通の事 (スコア:0)
アプリのコードは問題ないように見えるのに意図した通りに動かないのは、
OSやライブラリ(ときにはプロセッサ)のバグに起因していた、なんてのもよくある話。
炎上してるのは、
「それでもちゃんとテストしてれば、はじけたはずだろ」ってことと、
「ユーザーからバグ報告が上がってるのに放置すんなよ」ってことやね。
だれかやつらに「テスト駆動開発」について教えてやってくれ。
Re: (スコア:0)
普通の事と断言するほどに発生頻度が高く
普通の事と断言するほど予防できず見逃しも多い、と。。
Re: (スコア:0)
こんなのテストしても原因わからんよ。
Re: (スコア:0)
テストに幻想抱きすぎだよな
仕事は段取りってよく言うように実装用の設計時に品質はだいたい決まる
Re:エンバグするというのは、ソフト開発では普通の事 (スコア:1)
今回の問題を聞いて、PerlによるCGIが大流行していた古の時代に、
「適切にロックできていなくて、同時アクセスでファイルが壊れるアクセスカウンタ」
が世にはびこっていたのを思い出しました。
ユーザーコードなら、目に入れば「これ怪しい」って気づくこともできるだろうけど、
フレームワーク自体にこんな問題があるとは思いもしないよなぁ…
もうさ、 (スコア:0)
COCOAをディスコンして
どこかの国でうまく運用できているアプリをそのまま輸入して公式にしちゃダメなの？
それぞれの国で開発しなきゃいけない理由はなんかあるの？
Re: (スコア:0)
本質的には行動追跡のアプリだからそれを他国に任せたら他国に自国民の行動筒抜けになる可能性があるからじゃね
Re: (スコア:0)
＞それぞれの国で開発しなきゃいけない理由はなんかあるの？
それぞれの国で法律や対応策が異なるからですよ。
例えば評価の高い台湾やシンガポールのアプリでは、国民番号に紐付き24時間GPSで追跡し警察なども参照可能で
職員からの問い合わせに応答しない場合には録音録画が開始され大音量のアラームが鳴り通報します。
スマートフォン持たずに出歩くと刑事罰で全国民がインストール必須でアンインストールも禁止です。
日本で導入できますか？
（オフトピ）その情報ただしい? (スコア:1)
今台湾に住んでいますが、そんなアプリ聞いたことも無い。というか接触確認アプリ自体話題になる事がない。
観光地などの施設では記名制を取り入れている所もあるが、自分が体験したのはノートに入った日時と名前、電話番号を書くのみ。一箇所QRコードを読み取って表示された画面に電話番号と名前を入れる所があったぐらい。
隔離者の確認は携帯の電波を使用した大まかな位置情報と自治体職員などによる電話での確認のみ（在宅が確認できなければ警察が確認に来るが）。
台湾の「電子フェンス」 携帯の電波のみで自宅待機者を追跡 [eetimes.jp]
Re: (スコア:0)
いやむしろそれ導入したほうがいい。
権利ばかりかざして責務果たさない愚かな日本人にはお似合いだよ。
Re: (スコア:0)
蓮舫さんあたりに、「ここまでやらないとダメなんですよ！」とか
「甘いこと言っていたら収束できないんですよ！」と言って欲しいわな。
# 口が裂けても言わないだろうけど。
Xamarinのバグがーというが (スコア:0)
OSの処理系依存になるようなファイルI/O部分は共通コードで処理せずに処理系ごとに実装するだろ？
実行も処理系ごとにしてない、テストもしてないのが問題の本質だろこれ
Re:Xamarinのバグがーというが (スコア:1)
それXamarin.Formの開発者に言ってくれ。
Re: (スコア:0)
Xamarinでプロジェクト作った時点でiOS/Android用の個別処理を実装できるようになってるんだから、それを使ってiOSならNSUserDefaultsなり、AndroidならSharedPreferenceなり使えよって話よ
「System.IOの既定の動作としてOS・プラットフォーム判別して環境固有のAPI呼び出しまでやってくれ」と望むならわかるが、それはそれでXamarin.Formの開発者ではなく.NET全体の話だと思う
Re: (スコア:0)
じゃあ.Netの開発者に言ってくれ
なんなんだお前は
まだXamarinとかつかってるんだ (スコア:0)
っぱFlutterよ
Re:Githabの書き込み (スコア:1)
用を足したあとお尻拭かずにパンツ上げたらパンツが汚れました並の報告ですね。
# Githab?
Re:Githabの書き込み (スコア:1)
Re:Githabの書き込み (スコア:1)
障害の再現に成功した上で再現方法を明記しているのは有用な情報だと思いますが…
Re: (スコア:0)
バグチケットとしては有りだと思う
Re: (スコア:0)
言われてみれば、Windowsなら×ボタンで閉じるから終了処理を呼べるでしょうが、
そんなに不具合として挙げられるということは、
スマホアプリをタスクリスト（起動中アプリ一覧）から終了させるのは
Windowsで言うところのタスクマネージャからの強制終了に近いんでしょうか？
Re: (スコア:0)
> Xamarin.Formsがファイルを削除→移動している箇所で
削除して移動じゃなくて、ファイルをコピー後に削除すべきでしたというだけの話ですね。
素人はこの仕様を選んだ人かな。
Re:Windowsのrename()関数を書いたやつは頭がおかしい (スコア:1)
そうゆう場合はReplaceFile系のWin32APIを使うはず
.netだとFile.Replace
Re: (スコア:0)
おじいちゃんは新しいAPIのことは知らないからしょうがないよ。
Re: (スコア:0)
Windows XPの頃、APIよりコマンドプロンプト経由でのdel命令の方が安定して正確な動作だった経験が
未だにファイルをつかんで制御させてくれない時あるよね
Re: (スコア:0)
きっとアトミックに違いないと信じて行っている呪術プログラミングを世界中でやってるだけなんだよねこれが。
Re: (スコア:0)
かつては Transactional NTFS なるものでアトミック性も含めて保証されていたんですけどね
Xamarinで重要なアプリを書いたやつは頭がおかしい (スコア:0)
なるほど
こういうことですね
Re: (スコア:0)
「Windows環境に引きずられた」って言うけどXamarinはMonoが出発点でしかもモバイル先行だったしでwindowsあんま関係なくね？
Re: (スコア:0)
Xamarin.Formの開発者がWindowsに引きずられたんだろうて話では。
Re: (スコア:0)
風説の流布
Re: (スコア:0)
renameだけがクソみたいな指摘は止めろ。他はまともであるかのように勘違いする奴が出て迷惑だ。
だいたいWindowsに限らず、DOS時代からMicrosoftのOSは、ファイル操作全般がゴミクズなのは常識。
rename以前に置き換え自体が満足にできないクソ仕様なので、たかが使用中のファイルをアップデートする如きでリブート必須。
それすらリブート中にアップデートなどという意味不明な仕様なので、Windows 10のように「アップデート後に再起動ループ」などいう無間地獄に容易く陥る。
すなわち
設定情報を保存したプロパティをシリアライズしてファイルに書き出すロジックで、「.tmp」に書き出したのちに、元のファイルを削除してから、「.tmp」を元のファイル名にリネームするコードが書かれているという。そ
Re: (スコア:0)
アトミック性がないところでは悪くない方式だと思いますが……
昔、ネットワークドライブ上でExcelのファイルを上書き保存しようとしてできなかったことがあります。
クオータに引っかかっていたのですが、空き容量はもうちょっとあるはずなのに、と思ってよく見ると
＞「.tmp」に書き出したのちに、元のファイルを削除してから、「.tmp」を元のファイル名にリネームすするコードが書かれているという。
この動作をしていて、空き容量不足でテンポラリファイルの作成に失敗しているようでした。
これなら書き込みの途中で失敗しても元ファイルを破壊せずに済みますからね。
# 某ソフトは何も考えずに上書きするっぽくて、
# 保存中にスリープボタンを押してしまい、復帰後にもう1回保存すればいいかと思って
# 復帰させたらエラーで再起動がかかってしまい、結果としてファイルを壊したことがあるAC
Re: (スコア:0)
Windows環境に引きずられたXamarinの不具合を受けたんだから関係あるだろ。
Re: (スコア:0)
オフトピックモデで
Re:Windowsのrename()関数を書いたやつは頭がおかしい (スコア:1)
High Availability の世界だとあり得る話 (今回はそこまででもないのですが)。