This is a blog post by Soheil Moayedi Azarpour, an independent iOS developer. You can also find him on Google+. Have you ever had the following experience as an app developer? Before you submit your app, you perform a lot of testing to make sure your app runs flawlessly. It works fine on your device, but after the app is in the App Store, some users report crashes! If you’re anything like me, you
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
タイムラインに流れてきたこのリンク先の記事を見て下記の内容を書き込んだところ、いくつか反応を頂きました。せっかくなので、英語でのバグレポートの書き方について簡単にまとめてみます。ポイントは「英語に頼らずに英語を書く」です。 英語でのバグレポートが難しいという人は、日本語でもレポートが書けてない可能性を考えるべき。フォーマットに従って「現状の動作」「期待される動作」を書いて、後は再現ステップと再現環境を書けば、英語が理由で伝わらないということはあまり無いと思う。バグレポートの文章の大半は固有名詞だし。 **「問題となっている現状の動作」「期待される動作」「再現手順」を意識して書く** 「バグレポートを読む」という意識でいる場合、読み手が期待するのはこの3点だと思います。逆に、この部分が書かれていれば、コミュニケーションを成立させることができます。 「現状の動作」は、現象そのものを書きます。手
When your iPhone app crashes with 'BAD ACCESS' you're in trouble - a memory bug where you tried to call a method on a object that was already deleted. Instruments has support for NSZombie - a feature that makes it easy to find the source of the bug by showing you a full history of every alloc, retain, release, and autorelease of the object that caused the crash! Wow. Here's how: Basic steps are: R
Androidアプリのテストに関する課題 Android端末の普及は世界規模で増加の一途をたどっています。2011年秋冬モデルが発表され、発売予定のものを含むと日本で発売中のAndroidの携帯端末は100機種に迫ろうとしています。読者の皆さんの周囲を見渡しても、電車や街角でAndroidを採用したスマートフォンなど携帯端末を使用する人をよく見かけるのではないでしょうか。 そして、スマートフォンに留まらずタブレットやミュージックプレイヤー、電子ブックリーダー、POSレジ、テレビなど、さまざまなデバイスがAndroidを搭載し始めています。Androidの採用が増えるにつれ、Androidアプリの種類が増えるので、アプリの開発案件も増えることになります。実際、本稿を読んでいる開発者の方の中にも、すでにAndroidアプリの開発に取り組んでいる方も多いのではないでしょうか。 筆者も普段の業務の
追記:あとで分かったことがあったので一部書き直しました。 今日ひょんなことから XCode Tools の一部で /Developer/Applications/Performance Tools にある MallocDebug.app を使ってみた。 これ、便利すぎ。valgrind がないというだけで Mac OS X の開発は気が重かったけど、大体は要求をカバーしてくれそうだ。 ただ、このツールはGUIアプリのようにセッションが長いプログラムのデバッグ用に作られたようで、ターゲットが終了してしまうとそれまでの情報がすべて失われてしまうので、コンソールで動くちょっとしたアプリなどでは使い物にならない。 そこで、exit() で停止させることを考えて、GDB からターゲットを起動し、 set environ DYLD_INSERT_LIBRARIES=libMallocDebug.A.d
Information About News Tool Suite Supported Platforms The Developers Source Code Current Releases Release Archive Variants / Patches Code Repository Valkyrie / GUIs Documentation Table of Contents Quick Start FAQ User Manual Download Manual Research Papers Books Contact Mailing Lists and IRC Bug Reports Feature Requests Contact Summary Commercial Support How to Help Contributing Project Suggestion
2010年08月05日15:38 カテゴリiPhoneプログラム iPhone Objective-Cではないコードのメモリリークを特定するには(今回はソース付き) 今回はメモリリークの話です。 iPhoneでのメモリ管理ですが、Objective-Cのクラスをフル活用してコードを書いているウチは問題ないと思います。InstrumentsのLeaksを使えばコードのどの場所で確保されたメモリかが一目瞭然だと思うからね。 (きっとC++でもそんな感じに違いない) なーのーでーすーがー! 問題なのがCのmalloc()とかcalloc()とかrealloc()とか。これ、InstrumentsのLeaksでも「Malloc area 8K」とかって表示されるんで、その表示の中からメモリリークを探し出すのが至難の技….。 まぁメモリ確保時にクラス名の指定も何もないんだから仕方ないのは判ってるんで
ここは管理人pigeon6と同じようなコンピュータとプログラムとアレゲが好きなおさるさんのためのサイトです。たぶん。 Xcode環境でデバッグを行う際に役に立ちそうな情報をまとめました。 Xcodeはgdbのフロントエンドとして動作するビジュアルデバッガを提供していますが、VisualStudioなどを使い慣れていると、ぱっと見足りない機能があるように見えるというか、「あれ、コレってどうやるの?」みたいな事が、いくつかあります。 このページでは、そんな経験を何度かした私が関連ドキュメントの一部を調べて、これはと思った機能を紹介します。そんなわけで、Xcodeのデバッガの使い方がそもそも分からないというような初心者には適さない内容ではありますが、何となく使っているだけでは分からない、あるいは見落としやすい内容をメインに書いています。 なお、Guard Malloc(libgmalloc)につ
ここは管理人pigeon6と同じようなコンピュータとプログラムとアレゲが好きなおさるさんのためのサイトです。たぶん。 Guard Mallocはmalloc, callocなどで確保したメモリに対して不正な操作を行ってしまう類のバグの検出を助けるデバッグ用のライブラリです。Guard Mallocを使ってアプリケーションを実行すると、そうしたメモリに対してのバグがある場合、アプリケーションがバグの位置でハングアップします。 - Manual page for libgmalloc Xcode上でのGuard Mallocの使い方 メニューから「実行>Guard Mallocを有効にする」を選択して、チェックをつけるとGuard Mallocを有効に出来ます。Guard Mallocには各種オプションがありますが、これは実行時の環境変数をセットすることで設定します。 Guard Malloc
Google が公開しているソフトウェアの解説シリーズ(→その1 , その2)の続きです。今回は google-glog を使ってスタックトレースを表示する方法についてご紹介します。 C++ でプログラムを書いているとよく遭遇するのがセグメンテーション違反というエラーです。不正なアドレスへのアクセスなどによりセグメンテーション違反が起きると、通常、 UNIX 系の OS では SIGSEGV というシグナルによってプログラムが終了するとともに、 core というファイルが作られます。 core ファイルにはデバッガから参照できるいろいろな情報が残っていますが、多くの場合に役に立つのは、スタックトレースという情報です。スタックトレースを見れば、プログラムがどこでクラッシュしたのか、どのような関数を経由してそこにたどり着いたのかがわかります。プログラムがクラッシュした箇所を特定できれば、単純な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く