パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

バグや問題を「MSのせい」にする技術者、いませんか?」記事へのコメント

  • by yoshimo (15798) on 2008年08月28日 14時05分 (#1411305)
    Windows CE 5.0の.NET Framework 2.0(C#)で
    はまった内容:

    悪い例:
    Form form = new HogeForm();
    form.ShowDialog();
    form.Dispose();

    良い例:
    Form form = new HogeForm();
    form.ShowDialog();
    form.Dispose();
    form = null;

    最後にnullを設定しないと、このフォームがガベージコレクトされず、
    メモリリークします。なんだそれ。

    マイクロソフトのサポートに問い合わせたところ、
    マイクロソフト側でも現象を確認したそうで、
    回答が「最後でnullを設定してね」でした。
    マイクロソフトはバグとは言いませんでしたが、どう見てもバグですね。

    メモリリークするよ~、あんたのコードが悪いんでしょ~、
    なんとかしてよ~、とつつかれて大変でした。

    • by Anonymous Coward on 2008年08月28日 15時08分 (#1411383)
      Java屋さんです。
      いまどき Web アプリを作ると Encoding は ふつー utf8 ですよね。
      ある日、お客さまから文字サイズがころころ変わるバグがあるからさっさと直せとのご連絡。
      そういわれましても、そもそも表示文字サイズを変えるような処理をしていないのです。
      お客さまのところへ伺ったところ、IE6 で表示文字サイズを最大にしてご利用でした。
      確かに mouse cursor が anchor element の上を通るときに文字サイズが変わる。
      勘のいい方はお気づきのように、IE7 だと問題ありません。
      結局、IE6 の既知の問題とわかりました。

      リンクをクリックすると文字のサイズが中に戻る
      http://support.microsoft.com/default.aspx?scid=kb;ja;896315 [microsoft.com]
      公式な対策は、リンク元のHTMLの文字コードをShiftJISにてエンコードしてください、とのこと。

      すでに obsolette な IE6 だけのために utf8 をやめるわけにもいかず、
      かといってお客様は IE6 でないと動かない Web アプリを多用してるらしく、
      IE7 に入れ替えるのは無理とのこと。

      説明でお客様も一応は納得してくれたのですが、腑に落ちない様子なので、
      お客様の選択のひとつとして、IE6 と併用できる Firefox を紹介しておきました。

      まあ、そんな事例もあったということで。

      親コメント
      • Web制作を生業にしていてIEを蛇蝎の如く嫌わぬ者はいないのではないかというほど、アレには手を焼かされてきました。
        IEのバグリスト [infoseek.co.jp]をMozilla [infoseek.co.jp]やSafari [infoseek.co.jp]、Opera [infoseek.co.jp]と比較すると数の違いに驚かされます。しかも、これは独自仕様に基づく動作の違いを含みません。
        W3Cの仕様に基づき記述したものが記述通りに動かないのは、原因が何であれ使用者側から見ればバグでしょう。

        まあ既知のバグを回避するのも技術者の仕事のうちではありましょうが、こうも多いと完全回避が困難である場合も……
        親コメント
        • by Kazsa (25846) on 2008年08月28日 16時40分 (#1411479) 日記
          あー、それでみんなFlashに逃げるんですね。
          親コメント
        • by Anonymous Coward
          単に利用者が多いから報告も多いというだけの話だと思いますが。
          Bugzilla@Mozillaでコンポーネントをレイアウトだけに絞って検索しても星の数ほどバグが出てきます。
          確認されているセキュリティホールの数はOperaが断然少ないのですが、それは本質的にOperaが安全だからでしょうか?
          • Operaのシェアが一番低いから、ということはないですか?
            挙動とかレイアウトにかかわるものはわりに見つかりますが、
            セキュリティに関係するものは狙って探さないと見つかりにくいですし。
            (通常使用で表に表れない)
            • by Anonymous Coward
              Operaが本質的に安全だからですか? (そんなわけない、シェアが低いからに決まってるだろJK)という反語のつもりだったのですが。
              • by Anonymous Coward

                Operaが本質的に安全だからですか? (そんなわけない、シェアが低いからに決まってるだろJK)という反語のつもりだったのですが。

                大丈夫。ほとんどの人には通じている。通じている人はコメントを書かないだけ。

                #屋上屋を重ねているだけなのでAC。

          • by Anonymous Coward
            > 単に利用者が多いから報告も多いというだけの話だと思いますが。

            それだけでなく、
            たとえばFxのバグは見つかるごとに少しずつつぶされていますが、
            IEのバグは大半ホッタラカシなんですよね。メジャーバージョンアップ後ですら…。
    • by ich84 (33072) on 2008年08月28日 15時22分 (#1411394)
      ドライバとか開発してると、本当にMSのせいなことがよくあるんですよこれが!

      お願いだから直してくださいとMSに半年くらい頼み込んで、やっとパッチを出してもらった。これで安心と思ったら、サービスパックで元に戻りやがったー!!

      ということが、ごくごく最近にありました。SPへのパッチはいまだに出てません!
      親コメント
      • by Anonymous Coward
        私も、SPでドライバの挙動が変わった経験とかあります。
        Windows環境でしか再現しないし、テスト環境にSP全部用意とか厳しいから
        ホント勘弁。

        # ずいぶん前のことだけどAC
      • by Anonymous Coward
        SPのブランチを打つのがパッチのリリースより早かったんですかね。
        MSをもっとプッシュしてください。
        ドライバ開発者の皆さんの努力で快適なWindowsが維持されていると
        一ユーザーとして思います。
        みなさんの努力に感謝。
    • 変数のスコープにとどまったままとかそういうことじゃなくてですか? 変数のスコープから外れてるのにGCされないんだったら、どんなGC使ってんだよって思いますね。
      親コメント
      • by yoshimo (15798) on 2008年08月28日 15時12分 (#1411386)
        ちょっと説明不足でしたね。
        もちろん、スコープから外れても、ガベージコレクトされずに
        フォームオブジェクトが丸ごと残り続けてました。
        で、最終的にはOutOfMemoryExceptionになってしまいます。
        nullでリセットするようにしただけで解決しましたけどね。

        他にも、Windows CEの.NETの怪しい挙動をいくつか見つけており、
        (問い合わせてはいませんが)たぶんMSのバグだべ~と思っています。

        #↑で、こういう態度をとると
        # 「すぐにMSのせいにする技術者」
        # ってことになっちゃうんだな。
        # じゃあ一体どうしろと

        親コメント
        • # じゃあ一体どうしろと

          素人考えですが、その「Microsoft 製品のバグだろう」と思っている現象を Microsoft Connect [microsoft.com] で報告して他の人がバグであることを確認してくれれば、技術者相手には自分のせいでないと説得することができると思います。日本語の報告も受け付けていて [microsoft.com]、日本語の報告を Microsoft の担当者が英語に訳す場合もあるようです。 Connect はほとんど使ったことがないので、どのくらい他の人が再現に協力してくれるものかはわかりませんが。

          ただし、バグ報告を書くのは手間がかかるかもしれませんし、 Connect では技術者以外には説得材料にならないでしょうね。

          親コメント
        • なるほどー。formをnullにするだけで解決するってことは、スコープから出てもformが内部的にライブのままになってるんでしょうかね。とんでもないなあ。
          親コメント
        • by Anonymous Coward on 2008年08月28日 15時36分 (#1411409)
          「たぶんMSのバグ」って言うと嘘臭い感じがしますね.
          「おそらく .NET Compact Framework の garbage collection のバグです」とかいえば
          「MSのバグ」ほど馬鹿っぽく聞こえなくなりますよ?
          # 問題は何も解決しませんけど
          親コメント
      • by Anonymous Coward
        formの内部で使ってる何か、もしくは.NET Framework外の何かがリークする、ってんだろJK 誰もformがリークするなんて書いてない。
    • その1
      まだDOSが当たり前だったころ、当然16ビット用のアプリなんですが、
      スタック領域を8000hバイトと指定してMASMでアセンブルしたら、
      なぜか符号拡張されてFFFF8000hバイトの確保に走り、メモリ不足のアセンブルエラーとなりました。
      しょうがないので7C00hぐらいに減らして回避しましたが。

      その2
      VB 4.0のthreed.ocxは普通に使うだけでメモリリークする困ったやつなわけですが、
      これを使ったアプリが長時間連続動作で落ちるという状態になりまして。まぁ当然なんですが。
      開発元に連絡したところ、「それはMSのバグなんでうちは対応しない」とかなんとか抜かされまして。
      いや、そのコントロールを使う要求をしたわけでもないんだし、そりゃないでしょ。
      しょうがないので代わりに対策しましたよ。ええ。
      MSのバグだって免罪符にはならないのにね。

      ツールにバグがあるのはやむを得ないとして、最終製品に対してきちんと責任を持ちましょうという話。
      親コメント
    • C++でビルドしたものが、Win98SEだけ同じバイナリでメモリリークすることはありました。
      ポインタ変数にNULL入れるとそのときも解決しましたが・・・
      親コメント
    • by Anonymous Coward
      VBのときからそうでした。
      • by Anonymous Coward
        VBは関係ない。
        あれはGCでなくリファレンスカウンタでしかなく、NothingをSetする必要がある。
        しかしC#/VB.NETはGC。
        .NET Compact Frameworkはその手の不備ありまくりなので、null/Disposeは明示的にするのが吉。
        • > null/Disposeは明示的にするのが吉。

          だから、 Dispose() を明示的にコールしているのに、リソースが解放されないよ、変な実装だね。って話でしょう。
          親コメント
          • by Anonymous Coward
            ちげーよ。

            変数にnullを設定して参照をなくさないとGCが働かないのが不具合というのが元コメント。
            本来はスコープを抜けたら参照が破棄されるので一々nullを設定する必要はない。

            Dispose()で解放するリソースは、この場合はformの中。
            form自体は参照が残っているのでまだGCの対象外。
            Dispose()呼ぶだけじゃ駄目という悲しい現実。

            「「書かせること」が変わってない」は確かに同意。
            むしろ例外がある分余計辛いかも。
          • by Anonymous Coward
            (MSの)Dispose()なんて飾りです。エライ人にはそれがわからんのです。
        • by Anonymous Coward
          技術的な話じゃなく、「書かせること」が変わってないってことでしょ。
    • by Anonymous Coward
      面倒なものですなあ。

      ところでそれ、最近の流行でいえばRuby流というか、こういう感じには書けないんでしょうか?

      HogeForm.ShowDialog do |form|
          xxxxx
      end

      Rubyのブロックの使い方の1つとして、
      それこそ今回のよう(?)な、リソース開放の手順を隠蔽する道具として使う、というのが有るもので。

      open(filename) do |f|
        f.xxxx
      end

      などと書くと「ファイルを開いてブロック内でxxxxさせて、それが終わるとファイルを閉じる」ってのをやってくれる。

      こういう書き方が出来るならば、Disposeだろうが=nullだろうが何が来ようが怖くない。みんな隠蔽できるのだから。

      この
      • by Tsann (15931) on 2008年08月29日 8時28分 (#1411845)

        ところでそれ、最近の流行でいえばRuby流というか、こういう感じには書けないんでしょうか?

        HogeForm.ShowDialog do |form|
                xxxxx
        end
        using構文で書けます。

        using( var form = new HogeFrom() ){
          form.ShowDialog();
        }
        formのスコープが明確になるし、Dispose()の呼び出しも保証されます。
        親コメント
        • formのスコープが明確になるし、Dispose()の呼び出しも保証されます。

          そう。そしてusingは使っていないがちゃんとDisposeしているのにメモリリークするというのが元に書かれたバグでしょう。CE の環境がないので試せていませんが。

          HogeForm.ShowDialog do |form|
                  xxxxx
          end

          これをこんな風に書く必要があるんでしょう。

          HogeForm.ShowDialog do |form|
                  xxxxx
                  form = null
          end

          なんだそれと思ったらその感覚が正しい(笑)

          --
          LIVE-GON(リベゴン)
          親コメント
      • 一応、C#にはGCのタイミング以外でリソースを解放するための仕組みとしてのDispose、そして確実に(実は場合によっては確実じゃないことがあるようなないような・・・)Disposeを呼び出すためのusingという構文があるので、言語や実行環境としては問題はないと思います。

        問題は、.NET Frameworkという腐ったライブラリ。
        個人的には、Microsoftの製品は、上のレイヤーにいくほどダメな仕様になることが多いと思う。

        カーネルとか、.NET CLRとか、C#とか、すごく良くできていると思うんですけどねぇ。
        親コメント
    • by Anonymous Coward
      昔から出来るプログラマーは、なにも言われなくても バグ回避のためのコーディングをしてきました。 仕様どおりのコーディングしかできないやつはプログラマじゃなくてコーダーです。

コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell

処理中...