前言:---------- &学会如何调试bug&----------
1.在开发中如何调试程序 ------------------(请看==》步骤一 至步骤 五)2.使用过哪些调试工具 ---------------------腾讯的 bugly3.程序上线后，如何收集错误信息---------(请看==》步骤 六)4.bugly演示 --------------------------------- (请看==》步骤 六)5.NSLog进行调试 --------------------------请看小结后-NSLog调试
创建一个，叫 &调试-01-crash&.
假如，我们在这个项目中写一段错误的代码。如下:
错误代码示例
cmd + R，运行一下，会报下面这个错误，如下图所示: (插入一个空对象在1的索引位置)
这时我们就会想，我们在哪里犯了错误，在哪里插入了空对象，并有到处翻bug的冲动。但是我们这时设想我们会有上百个文件，我们怎么找呢？
-------------采用调用堆栈的方法-------------
先执行的在下面，后执行的在上面。
调用堆栈的详解
首先，要看一下，调用堆栈给我们带来了哪些信息，比如说上图所示，
① 程序启动的时候调用
-[UIWindow makeKeyAndVisible]
====&(在往上看)
② viewController调用
- [viewController viewDidLoad]
- [viewController demoCrash]
③ 然后看下面这个，在一个数组中试图插入一个对象
+ [NSArray arrayWithObjects：count:]
④ 在看到这个
-[__NSPlaceholderarray initwithObjects:count:]
⑤ 在往上看就崩溃了
这时，我们就知道了，在 #demoCrash# 方法中出现了上面所描述的错误。
⑥ 分析完毕
找到错误，定位方法如下图所示:
如果该项目，在真机上运行时，会怎么样？
** 项目会提示错误信息，调用堆栈不会显示。**
真机运行-显示结果
程序上线后，如何收集错误信息
这时，我们思考一个问题，任何一个，在做项目的时候都有可能会出现错误，比如说程序在上架的时候很有可能，有些错误没有改掉，或者说在测试的时候没有发现，就重复上架了。这时候，当用户运行时，就会产生崩溃。
===》那我们，出现一个问题，程序上线后，我们该如何收集错误信息呢？
对与这个，我们会通常，用第三方框架，在这里我们就用，QQ的bugly进行演示。
步骤 七 我们用QQ扫一扫，登录一下。就会进入下面的界面。
按照下面进行操作如图所示:
注册完毕后，会让我们，下载SDK，查看信息。
点击后进入这个界面
看使用指南Pod集成
pod集成完之后---& 初始化SDK
然后，我们找到 APPid
将 appid 填写到工程中，如下:
到这个时候，基本完成，我们运行一下程序。会看到下面这张图，里面什莫错误也没发现。刷新一下，也看不到崩溃日志。
原因:一般我们程序运行，发生崩溃，都会停留在下面这张图中所显示。它就是一个断点，断点停留在这里了，程序后面代码就不执行了，不执行的话，错误信息就提交不上去。
我们把程序安装到真机，运行一下，会出现闪退的现象。
在刷新一下，图上这个界面，会出现下面，找到日志，如下图:
点击错误日志后会出现如下图:
重点看这里:
通过上图我们会发现一个什莫细节呢？
我们导入了腾讯的第三方框架之后，即便我们的程序上架了，我们也可以知道这个会崩溃到哪里。
1.写在第一句
2.金玉良言
创建一个名为&NSLog&的项目工程，在创建一个PCH文件。如下图:
cmd + B 编译一下
假如，我们这个程序使用了两年了，我们一直用的NSLog进行的调试，突然一想，把NSLog替换掉。那我们就考虑用PCH.如下图:
main：我们要使NSLog打印的更可以对其进行如下图的设置:程序员遇到最难调试的bug经历分享最近看到一个来自国外网站Quora上的热门帖子《What&s&the&hardest&bug&you&ve&debugged?&|&你调试过的最难&BUG&是？》，觉得非常不错，再次分享给大家。这个帖子的原文作者叫做Dave&Baggett，伯乐在线&&&熊铎&翻译。以下是故事正文：回想起这个BUG，仍然让我有些痛苦。作为一个程序员，在发现BUG时，你学会了首先在自己代码中找问题，或许在测试一万次之后，你会把问题归咎于编译器。只有在这所有的都不起作用之后，你才会把问题归咎于硬件。这是我遭遇一个硬件bug的故事。抛开别的不说，我曾为《Crash&Bandicoot》写存储卡（读写）代码。对于一个自大的游戏程序员，这就像是在公园里散步一样轻松愉快，我认为只要几天就写完了，最终调试用了六个礼拜。在此期间我想尽了各种方法，但有个BUG始终没有被修复&&每隔几个小时就会发生一次。这实在是个烦人的BUG。这个BUG的症状是，当你需要保存你的进度时，代码会访问存储卡，而大部分情况下没有什么问题&但是偶尔读写会超时&没有任何明显的原因。一个短小的写入经常毁掉存储卡。玩家要保存进度，程序不仅不保存，还擦除他们存储卡上的全部东西。天哪。过了一段时间，我们在Sony的制作人Connie&Booth慌了。我们显然不能带着这个BUG发布游戏，而六个星期之后我对于问题出在哪一点线索都没有。通过Connie我们向其他&PS1&开发者求助：有没有人出现过像我们这样的情况？没有。绝对没有任何人在存储卡系统上出现任何问题。在你绞尽脑汁之后，你能做的唯一一个调试方法就是分而治之：一点点去除程序中的代码，直到留下的代码很少但你仍然出问题。像木雕一样去除没有问题的代码，留下的就是你的BUG所在。在这样的背景下挑战在于，视频游戏是很难去除某一部分的。在你删除模拟重力或者显示字符的代码后，如何运行游戏？你必须做的是用一个假装做真正的事情，但实际上只是做很简单的不会出现BUG事情的东西来替换掉整个模块。你必须写新的支撑代码来让这些玩意正常工作。这是一个缓慢而痛苦的过程。长话短说：我做完了。我移除了大片大片的代码，相当多，只留下了初始化代码&&就是准备游戏运行系统，初始化底层硬件等等。当然，我不能显示加载/保存菜单，因为我截除了所有的图像代码。但是我能够假装用户使用（不可见的）加载/保存屏幕并且请求保存，然后写入卡中。我最终以一个带有这个bug的很少量的代码结束&&但问题仍然随机出现！在大多数情况下没啥问题，但是偶尔会失效。基本上所有的Crash的实际代码都被移除了，但还是这样。这实在是莫名其妙：留下来的代码基本上都没做什么事。在那时&&估计是凌晨3点&&一个想法蹦了出来。读写（I/O）涉及精确定时。无论是硬盘、存储卡、蓝牙发送器&&随便啥&&做读写的底层代码都是根据时钟来的。时钟让不直接连接到CPU的硬件设备和CPU运行的代码同步。时钟决定了波特率&&数据从一头传到另一头的速率。如果计时有什么问题，硬件或者软件或者两者都会乱七八糟的。这真的，真的很糟糕，并且通常导致数据损坏。如果我们的初始化代码以某种方式弄乱了计时会怎么样？我又看了一遍测试程序中和计时有关的代码，并注意到我们将PS1上的可编程计时器设置到了1kHz（1000跳每秒）。这是比较快了，当PS1启动的时候，默认状态大概是100Hz。因此，大多数游戏将他们的计时器设置为100Hz。这个游戏的带头（和除我外的唯一）开发者Andy，将计时器设置为1kHz，使得Crash的动作计算更加准确。Andy喜欢这样做，如果我们要模拟重力，我们应该尽可能的提高精度！然而如果提高计时器频率莫名其妙的干扰了整个程序的计时，故而将这个计时器设置到存储卡的波特率上会怎样呢？我将计时器代码注释掉。然后我就无法复原这个BUG了。但是这并不表示BUG被修复了，这个问题是随机发生的。万一我只是运气好呢？几天过去了，我还是在玩我的测试程序。BUG没有再出现。我回到全部的Crash代码中，修改了加载/保存代码，在访问存储卡之前将可编程计时器重置为默认设置（100Hz），之后设置回1kHz。从此之后没有发现问题再次出现。但是&为什么？我重新回到测试程序上，试着检测当计时器设置为1kHz时出现的那些错误的模式。终于，我注意到这些错误出现在使用PS1手柄的人身上。因为我自己很少这样做，所以我没有注意到（为啥我要在测试加载/保存代码的时候用手柄）。但是有一天我们的美工等我去完成测试（我确定那时候我在爆粗口），而他紧张的摆弄着手柄。卡损坏了。&等下，怎么回事？喂，再来一次！&一旦我发现了这两件事是联系着的，就很容易重现BUG：开始写入存储卡，动一下手柄，存储卡损坏。在我看来完全是硬件BUG。我去找Connie告诉他我的发现。她转述给设计过PS1的硬件工程师。她被告知：&不可能，这不可能是硬件问题。&我跟她说问一下我能不能直接和他说。那个工程师给我打电话了，他用着他的烂英语，我用着我更烂的日语，我们争论一会。我最后说：&我给你一个30行的测试程序，让你在动手柄的时候能够出现这问题。&他答应了。他向我保证，这是浪费时间，而他正在一个新项目上很忙，但因为我们是Sony很重要的开发者，他会试的。第二天晚上（我们在洛杉矶，而他在东京，所以对于我来说是晚上而他是到了第二天），他给我打电话，不好意思的向我道歉。这是个硬件问题。我还是没有完全搞清楚问题到底在哪，但是我的印象中，从Sony总部的反馈听到的是，如果将可编程计时器设置到足够高的时钟频率，会影响到主板上时钟晶振附近的一些东西。这些东西之一就是存储卡的波特率控制器，同时也设置手柄的波特率。我不是搞硬件的，所以对于细节我相当模糊。但是主旨是主板上两个独立部分的串扰，以及手柄接口和存储卡接口数据发送的结合在&1kHz&的时钟频率下会导致丢位，从而数据丢失，以致卡损坏。这是我全部编程生涯中，唯一一次因为量子力学而Debug的问题。PS：PS1时代的索尼在游戏开发者心目中同今天的苹果无异，故事的主人，本文作者Dave&Baggett以及Sony的硬件工程师在对待问题时的严谨与专业精神应该值得所有开发者们学习与借鉴。只有认真对待每一个BUG，通过应用自动化测试等测试方法，才能让游戏得到玩家的喜爱，才能让自己得到同行的尊重。分享到：最近浏览暂无贡献等级暂无贡献等级暂无贡献等级暂无贡献等级暂无贡献等级暂无贡献等级暂无贡献等级暂无贡献等级暂无贡献等级暂无贡献等级暂无贡献等级暂无贡献等级暂无贡献等级暂无贡献等级暂无贡献等级暂无贡献等级扫描二维码关注最代码为好友"/>扫描二维码关注最代码为好友更多公众号：yllsscqqUI学习，每日一记。一位UI爱好者的日记本，你想了解多少？最新文章相关作者文章搜狗：感谢您阅读你碰到过的最难调试的 Bug 是什么样的？，本文由网友投稿产生，如果侵犯了您的相关权益，请联系管理员。开发的程序经常出现服务器内部错误，如何调试？
如题，但项目开始不是自己开发的，而是接手的，所以很难定位问题
服务器软件 Apache 2.1
2014年 9月29日
(775 威望)
请输入验证码:
[captcha placeholder]
或 后不会被要求输入验证码。
请输入验证码:
&&&& 或 后不会被要求输入验证码。
php.ini display_error 设置成 true ...
2014年 9月29日
(852 威望)
请输入验证码:
[captcha placeholder]
或 后不会被要求输入验证码。
提一个问题:
2012年 12月1日
(697 威望)
2012年 12月1日
(463 威望)
2012年 12月1日
(781 威望)
2015年 9月5日
(855 威望)
2015年 6月7日
(770 威望)
欢迎访问随意问技术百科，为了给您提供更好的服务，请及时反馈您的意见。}