AutoLayoutのエラーを紐解くときにやっていること - hiragram no blog
以前ふとこんなツイートをしたところ意外とLikeされた。 AutoLayoutのエラーがコンソールに出た時意味不明だけどviewのaccesibilityIdentifierとconstraintのidentifierに任意の文字列入れておくとメモリアドレスの部分がそれに置き換わるのでおすすめ— 🙌🐼ひらり🐼🙌 (@hiragram) 2017年6月8日 AutoLayoutの制約に矛盾があるときにコンソールにでるメッセージ これをみて直さないといけないときに自分がやっていることをまとめておく。 ビューのaccessibilityIdentifierを設定する コードからならhogeView.accessibilityIdentifier xib/storyboardならここ。 すると UIView:0xXXXXXXXXXXXXと出てたところがaccessibilityIdenti
iOS開発のデバッグツールchiselの紹介 - Qiita
(.lldbinit だと、Xcodeから起動したLLDBでは呼ばれないので注意。) Xcodeのlldbプロンプトで、helpとたたくと、chiselで使えるコマンド群が表示されます。さらにhelp <command> で、コマンドの詳細説明が出力されます。 (lldb) help The following is a list of built-in, permanent debugger commands: 〜略〜 pca -- Run Python function __FBPrintCommands_pca pcells -- Run Python function __FBPrintCommands_pcells pclass -- Run Python function __FBPrintCommands_pclass pinternals -- Run Python fun
パーフェクトなCRubyを目指して - 1行のバグ修正に潜む苦労 - - I am Cruby!
この記事はパーフェクトRuby Advent Calendar 2013 - Adventar の9日目です。 前の日のエントリーはパーフェクトRuby Advent Calendar 2013(8日目) Let's Sinatra Life - たちブログです。 まだ参加できますので、みなさまもぜひ。 パーフェクトRuby Advent Calendar 2013 - Adventar パーフェクトRubyRubyの仕様に大変詳しい同僚への献本をインターセプトして読ませていただきました。 さまざまな機能をまとめたとてもよい本だと思います。 著者のみなさまの苦労が偲ばれました。パーフェクトRuby (PERFECT SERIES 6)作者: Rubyサポーターズ,すがわらまさのり,寺田玄太郎,三村益隆,近藤宇智朗,橋立友宏,関口亮一出版社/メーカー: 技術評論社発売日: 2013/08/1
シェルスクリプトのデバッグは typeset または declare を使うと良いかも - よんちゅBlog
はじめに つい最近知った便利なデバッグ方法 (長年シェルスクリプトを書いているのに知らなかった。これが常識だったら恥ずかしい…) シェルスクリプトのデバッグでは echo で変数の中身を見るという原始的な方法をよく使うかと思います。 いわゆる プリントデバッグ というやつですね。 もう少し詳しいデバッグが必要な場合は、 set -x と set +x でデバッグしたい部分を囲むという方法もあります。 今回は プリントデバッグ で使う echo の代わりに typeset or declare を使うと良いというお話です。 プリントデバッグは typeset or declare を使おう typeset or declare は変数宣言などでよく使うコマンドですが、変数の中身を見るのにも使えます。 echo と比べて何が良いのかというと、変数の中身はもちろん変数名や変数の型も表示してくれ、
アセンブリ読んだら負けかなと思ってる - 誰かの役に立てばいいブログ
子供のころからできるだけ手抜きして成果を挙げることだけは長けている山本です。 今回は、C/C++ で作ったプログラムが運用中にクラッシュするときのデバッグ方法のお話しです。 開発中のデバッグは gdb などでソース追いながらデバッグできますが、運用中ですと strip していたり最適化していたりしてデバッグが難しくなります。 そもそも、いきなりクラッシュすると情報が残らずに困ってしまいます。そんなときどうするか。 Step1. スタックトレースを出力する こんな関数を用意しましょう。Linux 以外の人はそれなりに実装してください。 #include <execinfo.h> #include <unistd.h> void dump_stack() { void* bt[100]; int n = backtrace(bt, 100); backtrace_symbols_fd(bt,
コジオニルク - Android - 独自のバグレポート機能
Android - 独自のバグレポート機能 独自のバグレポートが必要な場合 Android 2.2になってから、Androidマーケット（現：Google Play）に公開されているアプリは実行時にクラッシュした場合（Exceptionがスローされた場合）に、 自動でマーケットにエラーレポートを行うかどうかをユーザに聞くような仕組みが導入された。 それが導入される以前は、デバッグの為に「独自でバグレポートシステムを仕込む」のが非常に有益だった。 Simeji作者様の記事が非常に参考になった。 しかし、現在でも以下のような状況下で、このバグレポートシステムを使うと有意義にデバッグが出来るので検討する価値はある。 業務でリリース前の開発中であり、テスト版のアプリを社内で配ってテストをして頂いている時 Google Playを介さずに野良アプリとして公開している時 ソースコード 以下のような観点
Enadroid: HierarchyViewer - Unable to debug device
On real devices the HierarchyViewer won't load the view hierarchy and you will get this error: [2011-08-15 14:46:28 - hierarchyviewer]Unable to get view server protocol version from device [devicenumber] [2011-08-15 14:46:30 - hierarchyviewer]Unable to debug device [devicenumber] For those who doesn't know the Hierarchy Viewer is a useful tool provided with the Android SDK, located in .../android-
escodegen + esprima で JS のデバッグをしたら捗りそう - tokuhirom's blog
以下のようなコードを実行すると console.log([ [1,1,8] [2,1,16] ]);このような結果になる。 [ undefined ]アレレーってなってたんだけど kazuho さんにきいたところ、 [1,1,8][2,1,16] => ([1,1,8])[(2,1,16)] => ([1,1,8])[16] => undefinedってことでした。 こんな時、Perl Monger ならとりあえず B::Deparse することによって解決の糸口をさがすんだけど、そういうの EcmaScript でどうすんすかね、ってなことを kazuho さんにきいたところ、esprima っていう es のパーサーがあるよって教えてもらったので、AST はとりだせたんだけど、AST をみても埒があかないので、AST からソースにおとす君がないかなーとさがしたところ const なんと
Leak Finder: a new tool for JavaScript
The latest news from Google on open source releases, major projects, events, and student outreach programs. Leak finder for JavaScript helps web application developers find memory leaks in their JavaScript programs. In garbage-collected languages, such as JavaScript, you cannot have traditional memory leaks by forgetting to free memory: when all references to an object are dropped, the object is g
Chromeのリモートデバッグ機能がすごい！ - Hacking My Way 〜 itogのhack日記
ここの動画で紹介されているリモートデバッグがかなり強力なツールなので紹介します。 事前準備 開発マシン側にadbというツール＆Android端末のUSBデバッグを有効にする必要があります。 開発してる人なら説明いらないので省略。 リモートデバッグを有効にする Android端末と開発マシンをUSBで接続して、端末が認識されていることを確認して下さい。 開発マシンのターミナルで以下コマンドを打ちます。 $ adb forward tcp:9222 localabstract:chrome_devtools_remote Android端末のChrome for Androidでメニューから 設定→デベロッパーツール→USBウェブでバッグを有効化にチェック 開発マシンのブラウザで下記URLにアクセスします。 localhost:9222 すると、Chrome for Androidのタブで開い
グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している
グーグルでは、社内のプログラマによって作り出される大量のコードの品質を保つため、チェックイン前にユニットテストとコードレビューが行われているそうです。しかし、コードが大量になってくると、ユニットテストやレビューをすり抜けるバグも少なからず発生します。 そこでコードの品質をさらに高めるために、グーグルでは「バグ予測アルゴリズム」を採用。バグがありそうな部分をレビュアーにアドバイスする仕組みを採用したとのこと。 そのバグ予測アルゴリズムとはどんなものなのか。Google Engineering Toolsブログに投稿されたエントリ「Bug Prediction at Google」（グーグルにおけるバグ予測）で説明されています。 ソースコードの修正履歴を基に予測 コードの中にバグがありそうな箇所を分析する手法としては、「ソフトウェアメトリクス」がよく用いられます。これはコードを静的に分析して、
__builtin_return_addressについて - Shohei Yoshida's Diary
__builtin_return_address関数の紹介。簡単にいうとある関数が どこから呼び出されたか知ることができる関数です。厳密には 該当の関数を終えたときにどの番地に戻るかということなの ですが、たいてい call命令などの次の命令を示すので、呼び出した 場所の特定も容易にできてしまいます。 私はカーネルデバッグ時に多用します。 ユーザランドであればデバッガを使うことが容易ですが、 カーネルだと若干面倒です。カーネルでもメジャーなアーキテクチャ カーネルデバッガが安心して使えるんですが、マイナーなアーキテクチャだと カーネルデバッガ用のコードが誤っている(経験あり)ということがあるので、 どうしてもprintデバッグに頼ってしまいます。 __builtin_return_addressではアドレスしか知ることができないので, objdumpや nmの併用が基本となります。 変数の
CocProxy | CodeRepos::Share – Trac
CocProxy めんどくさいことしない置換プロキシー 使い方 http://svn.coderepos.org/share/lang/ruby/cocproxy/proxy.rb をダウンロード `files' というディレクトリをつくる 置換したいファイルをてきとうにつっこむ ruby proxy.rb ポートとか表示されるのでブラウザの設定を変える デフォルトだと、 #{File.basename(req.path_info)}", #{req.host}#{req.path_info}", #{req.host}/#{File.basename(req.path_info)}", .#{req.path_info}", がスキャンされ、ヒットしたら置換されます。 例えば、http://example.com/test/foo/bar.css にアクセスすると files/bar.c
実践デバッグ技法 - 世界線航跡蔵
オライリー・ジャパンから『 実践 デバッグ技法 ―GDB、DDD、Eclipseによるデバッギング 』を頂戴した。 概要 オライリーの『実践xxx』『Mastering xxx』 という本は技術xxxに少し慣れてきた人が更にステップアップするための本という印象がある。そして、体系的な理論というよりは現場の常識というものを扱っている。 『実践デバッグ技法』は前者の印象には反する。これは本当にGDBの使い方と問題の切り分け方を手取り足取り教えてくれる本で、まだデバッガが何なのかすら分かっていない人こそ読むべきだ。 一方で後者の印象には合致する。これこそが『 Debug Hacks -デバッグを極めるテクニック&ツール 』で著者のよしおかさんが訴えていた点でもあった。つまり、今までデバッグの技法というものは理論化されそれが普及しているとは言い難い。にもかかわらず、現場では常識である。初心者はどう
革命の日々！ [書評] 実践デバッグ技法
献本御礼 なんで献本もらえたのかまったく不明なんだけど（＾＾； ちまたではデバッグ三部作のトリを飾る一作と呼ばれているらしい。 いちおう、DDDとEclipseについても書いてあるけど、メインはどうみてもgdb。なので、Linux上でC言語開発をする羽目になった新人プログラマが読むと、一気にスキルが上がってお得。 昔、新人教育をやっていた時代にこれがあったら、全員に買わせたかもしれん。 ちょっと、長いけど目次を引用 推薦の言葉 まえがき 1章 初心者にもプロにも役立つ予備知識 1.1 本書で扱うデバッガ 1.2 使用するプログラミング言語 1.3 デバッグの原則 1.3.1 デバッグの本質：確認の原則 1.3.2 確認の原則にとってデバッガの価値とは？ 1.3.3 その他のデバッグ原則 1.4 テキストベース vs. GUIベース（そして両者の折衷形態） 1.4.1 インタフェースの簡単な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Decode segfault errors in dmesg
GitHub - JakeWharton/scalpel: A surgical debugging tool to uncover the layers under your app.
GitHub - nette/tracy: 😎 Tracy: the addictive tool to ease debugging PHP code for cool developers. Friendly design, logging, profiler, advanced features like debugging AJAX calls or CLI support. You will love it.
http://acra.ch/
Eclipseを使ったAndroid Nativeデバッグ
