(lldb) po [self _ivarDescription] <DetailViewController: 0x7fc94b637db0>: in DetailViewController: in UIViewController: _view (UIView*): <UIView: 0x7fc94b63c360> _tabBarItem (UITabBarItem*): nil _navigationItem (UINavigationItem*): <UINavigationItem: 0x7fc94b63ae20> _toolbarItems (NSArray*): nil _title (NSString*): nil _nibName (NSString*): @"jAO-Jw-mTY-view-IBP-J8-Ec0"<__NSCFString: 0x7fc94b6380e
LeakCanary Squareがメモリリークを検出するライブラリ square/leakcanary を公開したので、さっそく使ってみたらすごく便利だった話です。 A small leak will sink a great ship Piwaiが書いたLeakCanaryの記事がこちらです。 LeakCanary: Detect all memory leaks! 要約すると、 Squareではビットマップキャッシュに顧客の署名を書いていたが、端末の画面のサイズ分のメモリを確保するので、署名をするときにクラッシュすることがあり、それがOOMの大半を占めていた。 Bitmap.Configを変更したり、OOMをキャッチしてGCを走らせたりしたが、問題の解決には至らなかった。 我々は間違ったアプローチを取っていたことに気が付いた。ビットマップの大きさではなくメモリリークが根本的な原因だっ
[速報]マイクロソフト、Webアプリ用のリモートデバッガ「Vorlon」発表。Node.jsとSocket.io利用のオープンソースソフトウェア。Build 2015 マイクロソフトが米サンフランシスコで開催中のイベント「Build 2015」。2日目の基調講演で、Webアプリケーションをクロスプラットフォーム対応にするツール「ManifoldJS」に続き、Webアプリケーション用のリモートデバッガ「Vorlon」が発表されました。 VorlonもManifoldJSと同様にオープンソースとして開発されています。下記はVorlonのWebサイト。Node.jsとSocket.ioを用いていると説明されています。 ManifoldJSで開発するようなクロスプラットフォーム対応のWebアプリケーション開発では、Webブラウザが備えているようなデバッガが欠けている。それがVorlonの開発理由と
個人開発者の方はこれで結構救われるんじゃないかな? Cocos2d-xを使うゲームはC++で記述するので、メモリ関連のバグに悩まされるケースが多いと思います。Xcodeでデバッグしてその場所を突き止められるのならいいのですが、メモリのオーバーランなんかだとしばらく問題なく動いた後に突然訳のわからないところでエラーが出てアプリが落ちるということになってしまいます。こうなると原因を特定することは非常に困難です。コンソールゲームの開発であればグローバルなnewを拡張するなど独自のメモリ管理の仕組みを使ってこれを検出するのが通常のようですが、少々難易度が高いです。自分もどうするか悩んでいたところ、stackoverflowにこんな記事を見つけました。 stackoverflow.com 注目は二つ目の回答。なんとXcodeでそれを検出することができるのだそうです。Edit SchemeのDiagn
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Charles を使うと PC 上に HTTP プロキシを立てて端末の通信をキャプチャし、リクエストやレスポンスの内容を覗いたり書き換えることが出来る。類似のソフトウェアとして Wireshark や Fiddler, Paros がある。 アプリの開発をしていてよくあるのは、APIがスタブで固定値しか返してくれない、異常系エラーのデバッグがやりづらい、という場面だが、Charles なら通信を好きに値を書き換えられるのでこれらに簡単に対処することができる。 Charles は Java アプリなので OS X だけでなく W
全文検索エンジンのGroongaでmrubyを使っているのですが、たまにCRubyと異なる挙動に遭遇することがあります。このようなときはmrubyに問題があります。特定のメソッドの挙動がおかしいときはmrubyのライブラリーの実装に問題があります。構文の使い方で挙動がおかしいときはmrubyのVMに問題があります。 mrubyの問題に遭遇するときは、なぜかmrubyのVMに問題があるケースばかり1なのですが、久しぶりにmrubyのVMにある問題を直そうとしたらデバッグの仕方を忘れていました。忘れても後から思い出せるようにメモしておきます。 詳細は後述しますが、基本的な流れは次の通りです。 問題を再現するスクリプトを作る。 mrubyをデバッグビルドする。 mrbc -vでスクリプトの構文木(?)を確認する。 GDB上でmruby XXX.rbを走らる。 src/vm.cの中で問題のラベルが
Xcodeにはデフォルトでヒープ領域(mallocやnew)のアクセスオーバーランを 検知してくれる機能があります。 ただ、一発で検知してくれません。確実に検知する方法をここでは紹介します。 例えば、以下のようなヒープ領域をオーバーランするサンプルを使います。 - (IBAction)handlerA:(id)sender { // オーバーラン char* buffer = malloc(1024); memset(buffer, 0x0, 2048); free(buffer); } このメソッドを何回か実行すると以下のようなメッセージが表示されます。 1回ではなく何回かというところが重要です。 MemoryLeakBuster(55357,0x1f64a28) malloc: *** error for object 0xca53804: incorrect checksum for
April 20, 2014 Until very recently, if I was debugging a program, I practically always did one of these three things: open a debugger look at the source code insert some print statements I’ve started sometimes debugging a new way. With this method, I don’t look at the source code, don’t edit the source code, and don’t use a debugger. I don’t even need to have the program’s source available to me!
この記事のオリジナルは voxxed に投稿されたものです。 JavaScript関連の問題を抱えるチームをサポートする仕事を通じて、いくつか共通の問題点があることに気づきました。もしあなたもJavaScriptに対するイライラを感じているのであれば、この記事は何らかの助けになるかもしれません。おことわり:私がお教えするヒントはすでにご存知のものもあるとは思いますが、うまくいけば、多少なりとも有用な情報があるかもしれません。特にエンタープライズアプリケーションやCMSソリューションを構築する際に有効なヒントです。チームの誰もが話したがらないCMSのコードについてお話しします。いずれも必要に応じて採用できるものです。 debuggerステートメント 大半のブラウザでサポートされているにもかかわらず、JavaScriptを書く際に最も活用しきれていない機能の1つです。debuggerステートメ
Everything You Need for Reverse Engineering Hopper combines powerful analysis capabilities with an intuitive Mac-native interface, giving you professional-grade tools at an affordable price. Hopper Disassembler for Mac requires macOS 12.4 or higher. Native UI Built with a blazingly fast, beautifully polished Cocoa interface that prioritizes keyboard shortcuts and native macOS integration for a smo
http://www.objc.io/issue-19/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 objc.ioはベルリンのメンバを中心に、月替りでiOS関連技術の特定のテーマに絞って発信しているブログ。もう既に知名度はかなり高いかと思いますが、毎月ものすごく力の入った特集ゆえに、その分ボリュームも相当で、読むのも大変というか、時間がないから読めてない人もいるかと。今月は#19としてデバッグの話題です。 Peter Steinbergerの「デバッグ : ケーススタディ」では、UIKit上のバグをLLDBで対処した話を紹介。 「デバッガーでのダンス - LLDBのワルツ」において、Ari GrantはLLDBの使い方を詳説してくれています。 「DTrace」はiOSシミュレータでしかまだ利用で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く