LLDB Cheat Sheet
lldb_cheat_sheet.md LLDB Cheat Sheet A complete gdb to lldb command map. Print out Print object (lldb) po responseObject (lldb) po [responseObject objectForKey@"state"] p - Print primitive type Breakpoints List breakpoints br l br delete - Delete breakpoint (lldb) br delete 1 br e - Enable breakpoint br di - Disable breakpoint b - Add breakpoint (lldb) b MyViewController.m:30 br set - Add symbolic
Dockerコンテナが遅くなるもう一つの原因 | POSTD
前回の ブログ記事 では、Kubernetesの話と、 ThoughtSpot がKubernetesを開発インフラのニーズに合わせてどのように取り入れたかをご紹介しました。今回はその続報として、最近の興味深いデバッグ経験について少々駆け足になりますがお話ししていきます。本記事も「コンテナ化と仮想化はノットイコールである」という事実に基づいており、たとえcgroupの上限がどれも高くない値に設定されホストマシンで十分な演算能力が利用できるとしても、コンテナ化されたプロセス同士がリソースの競合を起こす場合があることを示したいと思います。 ThoughtSpotでは内部のKubernetesクラスタで 多数のCI/CDや開発関連のワークフロー を稼働させており、ある1点を除いては全てが順調でした。唯一問題だったのは、ドッカー化された製品コピーを起動すると、パフォーマンスが期待を極端に下回るレベ
Errorから行番号を取得する。 - うなの日記
Errorを使うと、Errorを作成した行の番号やスタックの情報を取得できます。 FireFoxのみ。 IE6では行番号、スタック情報ともに取得できませんでした。 var stdout = document.getElementById("stdout"); var error = new Error(); stdout.innerHTML += "message: " + error.message + "<br/>"; stdout.innerHTML += "name: " + error.name + "<br/>"; stdout.innerHTML += "lineNumber: " + error.lineNumber + "<br/>"; stdout.innerHTML += "number: " + error.number + "<br/>"; stdout.inne
最近のPerlのデバッグ - ✘╹◡╹✘
Perlよく分からないけど最近こうやってデバッグするようにしてる。 Data::Printer これまで値の確認にはData::Dumperを利用していたけど、程良く整形して色付けしてくれるData::Printerを使うようになった。use Data::Printerの代わりにuse DDPというエイリアスでも利用できる。useするとpという整形出力用メソッドを提供してくれる。Rubyで言うと、ppを利用していたのがap(=awesome_print)を利用するようになったというイメージ。これは適当にSelenium::Remote::Driverクラスのインスタンスをpメソッドで出してみた図。 Carp::REPL REPLはコード中で処理を止めてPerlの対話環境を開くやつ。これまで使ってなかったけど、良さそうという話をTLで見かけたので、適当にData::Printer入れて値確認
chromeデベロッパーツールでjavascriptのデバッグをする -node.jsもあるでよ- - tumblr
ソースコードリーディングとかしてると、ただコード読んでてもどうしようもなく、オブジェクトの中身や変数などを見るためにデバッグツールを使いながらでないとやっていけないことが今になって分かりました。自分でもどうしようもなくアホだと思いながら戒めのために覚書。 デバッグツールの機能 僕自身まともに触れる言語はjavascriptとphpくらいなもので、どちらもeclipseのようなIDEを使わず頑なにvimを使って組んできました。phpの場合はxdebugと連携させる方法*1や、javascriptならrhinoなんかを入れてquickrunとかって方法も考えられますが、僕はある程度は知っていながらもひたすら標準のスタックトレースやalert,console.log,console.dirばかりしていたので、まずはIDEなどに搭載されている一般的なデバッグ機能を復習をかねて覚書。 ブレークポイン
デバッグ力: よく知らないプログラムの直し方 - 2011-12-06 - ククログ
クリアコードではMozilla製品やRuby関連の開発だけではなく、広くフリーソフトウェアのサポートもしています。もちろん、サポート対象のソフトウェアの多くは私達が開発したものではありません。しかし、それらのソフトウェアに問題があった場合は調査し、必要であれば修正しています。 このようなサポートが提供できるのは、もともと、私達がフリーソフトウェアを利用したり開発したりしているときに日常的に問題の調査・修正をしていたからです。ソフトウェアを利用していると、問題に遭遇することはよくあることです。そのソフトウェアがフリーソフトウェアの場合は、開発者に問題を報告し、可能ならパッチを添えます。このとき、そのソフトウェアの内容を完全に把握していることはほとんどありません。しかし、それでも修正することができます。 それはどうしてでしょうか？今まではどのようにやっているのかを自分達でもうまく説明できなかっ
差をつけるデバッグ術！ ～ 知られざるログ出力 - Web/DB プログラミング徹底解説
突然質問です。 問題が発生したことを知るためには、どこにログを出力しますか？ テキストファイル？ イベントログ？ データベース？ ・・・ う・・・ まぁ、いいかもしれません。 ・・・ 他にはありませんか？ 実は、意外と知られていないですが、ログの出力にとても有効な場所があるんです。 特に内部データ出力、内部動作のトレースログなど、データ量が多いものは、 テキストに落としては重い。 リアルタイムに見られない。 という問題があります。 そういう時に、とても有効です。 リアルタイムに見られて、「軽い」 場所があるんです。 それはズバリ、デバッガです。 「え？ だどさん、開発のときの話だったの？リリースしてからだと思ったよ」 いえいえ。 もちろん、開発時も使えますが、開発時の話だけではありません。 本番環境にリリースしてからも有効なんです。 Windows API には OutputDebugSt
WM_PAINTで例外を投げたら残当したでござる - 名古屋３１３の日記
C++, win32 | 16:19 WM_PAINTで例外対策にBOOST_SCOPE_EXITを使って描画中に例外が飛んでもちゃんと描画終了するようにしたぞと粋がっていたら思わぬところから伏兵が現れました。 // 適当なプロシージャの中身 case WM_PAINT: { BOOST_SCOPE_EXIT((&hwnd)) { // たまたまDirect2Dを使ってたのでEndPaintとかではない ValidateRect(hwnd, nullptr); } BOOST_SCOPE_EXIT_END; // 描画する throw std::exception(); // ドヤ顔で例外を投げる break; } 問題はcatchした例外をMessabeBoxで表示した場合です。 try { // ウィンドウ作って表示したりメッセージループ回したり... } catch(const st
トムとマイケル - Emacs ひきこもり生活
トム「やあ、マイケルどうしたんだ。やつれた顔して」 マイケル「やあ、トム…どうしたもこうしたもないよ。全くバグがとれないのさ」 トム「ふーん?どこでどんなふうになっているんだい?」 マイケル「それがわからないから困っているのさ…!」 トム「ん?」 マイケル「このソフトなんだがね、起動中にどこかで無限ループしているようなんだよ。だけどどこかわからなくって」 トム「gdbの中で走らせて、killしてやったら?」 マイケル「そうするとほら」 % gdb --args ./src/hengband -- -n1 GNU gdb (Gentoo 7.2 p1) 7.2 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses
JavaScriptのデバッグTips - os0x.blog
JavaScript Advent Calendar 2010 8日目担当のid:os0xです。 JavaScriptネタは案外範囲が広くて色んなネタがあるので、毎回が楽しみですね。 さて、私はデバッグをネタにしたいと思います。テストではなくデバッグです。誰かが書いたコードをメンテナンスしなきゃー、とか。jQueryプラグイン導入しようとしたけど、なんかうまく動かないーみたいなケースのおはなしです。 JavaScriptのデバッグは大変なので、多くの方が日々苦労されていると思います。なぜJavaScriptのデバッグが大変なのか少し整理してみましょう。 ブラウザ依存 まず、なんといってもJavaScriptはウェブブラウザ上で実行されるので、環境が一定ではありません。特定の環境だけを対象にJavaScriptを書くことは滅多にありません。PC向けではIE、Firefox、Chrome、Sa
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
vebugger screencast
http://www.non.ssme.org/gw/wiki/?c00000070
Charming Python: Functional programming in Python, Part 3