Chrome OS アップデート後にログインできなくなるトラブル、原因は 1 文字の Typo 69
ストーリー by headless
修正 部門より
修正 部門より
先日リリースされた Chrome OS 91.0.4472.165 ではアップデート後にログインできなくなるなどのトラブルが報告されていたが、原因は 1 文字の Typo だったようだ(Android Police の記事 [1]、 [2]、 The Verge の記事、 SlashGear の記事)。
問題発生を受けて Google はこのビルドの提供を中止したが、既にインストールしてしまった場合はログイン画面から先に進めなくなるほか、最悪の場合はブートループに入ってログイン画面にも到達できなくなることもあったという。
7 月 21 日には問題を修正した 91.0.4472.167 がリリースされた。変更された vault_keyset.cc の diff をみると、修正前は2つの条件式のビット論理積 (&) を評価していた部分で、「&」が1つ追加されて論理積 (&&) に修正されている。
問題発生を受けて Google はこのビルドの提供を中止したが、既にインストールしてしまった場合はログイン画面から先に進めなくなるほか、最悪の場合はブートループに入ってログイン画面にも到達できなくなることもあったという。
7 月 21 日には問題を修正した 91.0.4472.167 がリリースされた。変更された vault_keyset.cc の diff をみると、修正前は2つの条件式のビット論理積 (&) を評価していた部分で、「&」が1つ追加されて論理積 (&&) に修正されている。
なんで？ (スコア:3, 参考になる)
`key_data_->label().empty()`に副作用がないなら条件付きか否かで変わらなくない？
と思ったが、C++だと&はビット演算で両方trueでもfalseになることがあるのか。
&&と&は条件付きかだけじゃなく評価の仕方が違うのね。
C#で両辺boolなら無視できるパフォーマンス上の問題でしかないからピンとこなかったわ。
Re: (スコア:0)
C#とかJavaでも両辺が整数とかだったりすると…
C＃とかJavaだと評価の仕方が違うというかboolとそれ以外で事実上全然別の演算子ですね。
Re: (スコア:0)
C#は演算子オーバーロードがあるのでなんでもあり。
ただifの条件にbool以外は入らないからこういう問題はまず起こらない。
boolへの暗黙の型変換が定義されてれば起こせなくはないがまぁ起きない
Re: (スコア:0)
確かに&はビット演算ですが今回の原因はビット演算だからではありません。
&&はショートサーキット評価で左の値がfalseのときは右側が実行されませんが、&では左の値に関わらず右が実行されてしまいます。
key_data_の定義は
base::Optional<KeyData> key_data_;
となっており、base::Optionalというのはstd::optionalのChromium版の実装です。
左側では key_data_.has_value() と値が存在しているかどうかをチェックした上で、右側で key_data_->label() とデータにアクセスしていますが、has_value()がfalseならアクセスすべきデータが存在しないのでundefined behaviourとなります。多分nullptrへのアクセスでクラッシュしますね。
Re: (スコア:0)
あーnullアクセスか。これなら普通だな。勘違いしてた。
メンバアクセスがアロー演算子 [github.io]と(若干良く分かってない)。
if(!(key_data_ is null) && !key_data_.label().empty()){ return key_data_.label(); }
相当か。
この辺null条件演算子が出来てからだいぶ楽になったなぁ。
Re: (スコア:0)
unique_ptrとかならnullアクセスになるだろうけど、今回はOptionalだからnullアクセスにはならない。
未初期化なデータ領域へのアクセスでのUB。
Re: (スコア:0)
Cだと演算優先順位も微妙に違うから ことによっちゃ大事に
リグレクションテスト (スコア:1)
OSにログインできるかどうかなんて、一番基本的な動作だと思うのだけれど、リリース前にリグレクションテストとかしてないのか?
グーグルのサービスってみんなそういうものなの?
一寸怖い。
Re:リグレクションテスト (スコア:2, 興味深い)
機能の確認どころか、電源入らなくなるというバグあってもリリースされるし、修正されずにバグ残ったまま、次のリビジョン出すのでリリース前にテストは、おそらくやってない。
https://issuetracker.google.com/issues/172225953 [google.com]
アップデートの無視とかできればいいんだけど、Chromebookはそれも出来ないからなぁ
Re:リグレクションテスト (スコア:2, おもしろおかしい)
グーグルのサービスってみんなそういうものなの?
そういうものですよ。
永久β版でおなじみのグーグルですから。
Re: (スコア:0)
これは本当にそう思う。
ワンパス通せば100％見つけられる内容なんだが、となるとまったくテストしていないんだろうなと思ってしまう。
Re: (スコア:0)
さすがに認証周りを書き換えて起こったミスではないよね?
逆に上手いこと書き間違えたら、アカウント名・パスワードを無視して何でもログインできるようになってたかもしれない、とかそういう部分の修正ではないんだよね?
そこがテストされてないとかだったら危なすぎる。
ログインが完了してデスクトップを準備してる途中で転けて振り出しに戻る、だよね?
Re: (スコア:0)
どう覚えたらリグレッションをリグレクションって覚えられるの？ リフレクションに引きづられてるのかな？
Re:リグレクションテスト (スコア:2, おもしろおかしい)
投稿前にリグレクションテストとかしないからじゃね？
Re: (スコア:0)
リザレクションかも。
Re: (スコア:0)
Gboard使ってるんだろ
Re: (スコア:0)
結果から見ると、わかる通りこれはテストしてないですね。
>グーグルのサービスってみんなそういうものなの?
すべてのサービスにおいてそうであるかわ不明だけれども
少なくともChromeOSではそうであることが分かったし
WebブラウザのChromeも、2017年に起こしたセキュリティ・
インシデントからしても、そんな状況であることは分かっていたので
さも驚きはしない。
Re: (スコア:0)
手広く作ると自分で使わないものを作らせるケースも出るわけで
Googleに限らずものづくりのあるあるではないかと
Re: (スコア:0)
製造業や建築業のように「テスターを雇う」だけで済むのに、なぜITはそうしないんだろうね。
費用効果分析した結果、「テスターの人件費＞損失額」と考えているんだろうか。
Re: (スコア:0)
そもそもタダで配ってるものだから損失がないし、訴えられても会社か株主が払うだけで責任を取る奴がいない。クソみたいな業界。
それより (スコア:1)
> 2021 年 9 月 30 日より、Google ブックマークはご利用いただけなくなります
さらっと告知されていました
Re: (スコア:0)
今初めて知りました。ありがとう。
chrome以外のブラウザからも使えるから結構便利に使っていたのだけど、今後どうしよう。
Re: (スコア:0)
そうそう。
どうしようかな。
Re: (スコア:0)
検索してください
ネットアクセスする前に必ずGoogle様に情報送る、という有り難い変更でしょうし
タイミングが悪いね (スコア:0)
Chromebookを採用した小中学校は大丈夫なのでしょうか？
この日付ですと、午前中授業や終業式に入るか入らないかのタイミングです。自宅に持ち帰って活用するように文部科学省からは通達が出ているけど、自宅でいきなりログインできないということになったら大変でしょう。
自宅に持ち帰る対応が準備できていない学校も多いようなので、そちらは二学期の授業が始まってから混乱が発生するのかもしれません。
ゲストログインができない設定にした教育委員会もあるだろうし、パワーウォッシュもできるのかどうか。USBからの回復策とか教員側は何も把握していないでしょう。さて、どうなるのか。
自分のChromebookは、職場に放置したままなので明日休日出勤して確認します。土日に使用する必要があるんですけどねぇ・・・。
Re: (スコア:0)
自業自得。
問題が起きて困るようなところにChromebookなんかを導入すんなよ。
Googleクオリティなので (スコア:0)
驚きはないです
ここはスラドですよ (スコア:0)
Typoごときで恐れをなしてはいけない
Re:ここはスラドですよ (スコア:1)
寿限無に出てくるやつな
Re: (スコア:0)
たいぽたいぼたんぼしゅーりんがんの
Re: (スコア:0)
typo type typo のシューリンゲン？
関連リンク (スコア:0)
どうしてこれが無い！
iOS7.0.6で修正された「最悪のセキュリティバグ」はありがちなコーディングミスで発生していた
https://apple.srad.jp/story/14/02/24/094232/ [apple.srad.jp]
Re: (スコア:0)
「バグだ」という以外の共通点はないからね。全世界で仕事や学業に使われてる実用的な道具と意識高い系の玩具ではカテゴリーは全然違う。
Re: (スコア:0)
どんな大企業でも、コピペとコピペミスとtypoは永遠に続く課題だなぁ。
アンバサンド１つと２つで意味が変わるとか (スコア:0)
こういったものを廃止していった方が良いのではないかね。
昔は１文字でも文字数を削減するために、こうしていたのだろうけれど、今は間違いの元じゃん。
Re:アンバサンド１つと２つで意味が変わるとか (スコア:1)
逆に、同じ意味で言語によって違う表現とかもなんとかしてほしい。
else if
elseif
elsif
elif
Re: (スコア:0)
if ( 〜 ) { 〜 } else if ( 〜 ) { 〜 } else { 〜 } は大抵 ( ( 〜 ) && ( 〜 ) || ( 〜 ) && ( 〜 ) || ( 〜 ) ) と同等。
Re: (スコア:0)
論理学的にはどっちもANDだからな。省略とかそういう問題ではない。
Re: (スコア:0)
数値を暗黙的に理論値にキャストできるのが問題なだけ。
今日的な処理系使えばいいだけ。
ちゃんとウォーニング見ればいいだけ。
Re: (スコア:0)
論理値な。あと今回は逆やろ。
意味的には boolean なのを 1bit 数値と見なせるから & が意味を持ってしまう。
Re: (スコア:0)
でも半角アスキーの記号はこれ以上絶対増やせないし
Re:アンバサンド１つと２つで意味が変わるとか (スコア:1)
Re: (スコア:0)
つUNICODE
Re: (スコア:0)
記号にする必要ある？問題のソースコードC++だから、現に&&の代わりにandというキーワードが使える。
Re:アンバサンド１つと２つで意味が変わるとか (スコア:1)
iso646ってもうじきC++から削除される予定じゃなかったっけ…
Re: (スコア:0)
トライグラフとciso646ヘッダは廃止されたけど代替表現は残ってる。
Re:アンバサンド１つと２つで意味が変わるとか (スコア:1)
ああ、消えゆく存在なんじゃなくて、キーワードに昇格しつつある？
Re: (スコア:0)
単なる文字数削減じゃないから両方仕様としてあるんだけどね…
Re: (スコア:0)
a = b 代入
a == b 比較
a * b 乗算
a ** b 冪乗
a < b 比較
a << b ビットシフト
etc...
寄ろ惜しくお願いしまーす！ (スコア:0)
で、ハッピーエンドやね