程序调试

转载于：http://blog.chinaunix.net/uid-23381466-id-309369.html arm-linux 的gdb移植分为两种情况.一种是交叉调试版。 这一种模式是需要编译一个arm-linux版本gdbserver (GDB的stub模块).然后再编译一个X86版本交叉调试的gdb.为了与桌面版本身的gdb 区别开来，一般改名为 arm-linux-gdb。两者通过串口或者网络进行互联。 还有一种是干脆把整个gdb移植成一个ARM的本地版。在开发板上直接用gdb来调试。 前一种方法是比较正统的方法。它gdbserver可以通过arm-linux-gdb直接在host上单步调试target的应用程序。.并且可以与图形界面调试器配合进行图形界面调试。缺点就是target资源较少。因此单步调试的速度并不是太快。因此实用性不算太强。 如何交叉调试 arm-linux的本地版一般只能做字符界面的。界面没有支持GUI的交叉调试版友好。而且单步调试速度也不算快。但是有几大大优点: 1.定位程序退出所在函数. 2.判断程序退出的原因 3.通过条件断点分析异常情况时运行环境. 用本地版gdb运行程序时，当程序因段错误或其它原因退出程序时。可以通过gdb bt(即backtrace)来查看最后运行的堆栈。来判断出错时是在哪一个函数里退出。这样会大大加快定位错误的速度

1. linux下编译C程序使用cc gcc g++ 编译C++程序使用 g++。 2. 调试程序使用gdb。 3. 调试过程主要参考以下两篇文章： http://blog.csdn.net/haoel/article/details/2879 http://blog.csdn.net/haoel/article/details/2880 4. 今天在Linux上用GDB进行程序调试的时候，发现提示： No symbol table is loaded. Use the "file" command. 导致这个错误的原因一般是：在交叉编译时没有加-g选项. 所以在编译程序时一定要注意加上-g这个选项，尤其在写Makefile文件时， 一定不要偷懒，仔细检查，确认每个编译条件都添加了-g选项。 来源： https://www.cnblogs.com/ZJUKasuosuo/archive/2012/08/27/2658038.html

使用 IAR 进行程序调试，但调试特别慢，每次停到断点之前都要等上几秒钟，单步调试难以想象的痛苦。记忆里的 IAR 不是这样的。 尝试了几次，总结了规律，程序看起来总是走在汇编窗口里，不是总在 C 窗口里执行，只要汇编窗口，就会在下次停到断点前自动打开汇编窗口。这种情况通常是 C 代码于程序代码对不上才出现，比如没有在 C 编译器里加调试信息，或者进行了程序优化，但是我的配置是正确的。 尝试了各种修改设置都没有解决。后来干脆删掉了项目目录下的“settings”和“ProjectName”文件夹，重新打开 IAR 会自动重新生成这两个目录。之后再调试，发现不再慢了。 注：ProjectName 是与项目工程同名的文件夹，这个文件夹是由 IAR 自动生成的。 怀疑是这两个文件夹中的某些文件没有正确更新或与当前项目有所差异导致的问题。 来源： CSDN 作者： lionchan187 链接： https://blog.csdn.net/desert187/article/details/104734988

测试与调试（负责人：孙媛媛） 　一、功能检查 　　1 、功能是否齐全，例如：增加、删除、修改 　　2 、功能是否多余 　　3 、功能是否可以合并 　　4 、功能是否可以再细分 　　5 、软件流程与实际业务流程是否一致 　　6 、软件流程能否顺利完成 　　7 、各个操作之间的逻辑关系是否清晰 　　8 、各个流程数据传递是否正确 　　9 、模块功能是否与需求分析及概要设计相符 　　二、面向用户的考虑 　　1 、操作方便性，如：按键次数是否最少 　　2 、易用性，面对用户的操作是否简单易学 　　3 、智能化考虑 　　4 、提示信息是否模糊不清或有误导作用 　　5 、要求用户进行的操作是否多余，能否由系统替代 　　6 、能否记忆操作的初始环境，无需用户每次都进行初始化设置 　　7 、是否不经确认就对系统或数据进行重大修改 　　8 、能否及时反映或显示用户操作结果 　　9 、操作是否符合用户习惯，比如：热键 　　10 、各种选项的可用及禁用是否及时合理 　　11 、某些相似的操作能否做成通用模块 　　软件数据处理测试用例模板 　　一、输入数据 　　1 、边界值 　　2 、大于边界值 　　3 、小于边界值 　　4 、最大个数 　　5 、最大个数加 1 　　6 、最小个数 　　7 、最小个数减 1 　　8 、空值、空表 　　9 、极限值 　　10 、 0 值 　　11 、负数 　　12

一、Codeblocks调试STL的问题： 不管你是Windows还是Linux的C/C++程序员，C::B都是一个非常不错的集成开发环境，如果你经常使用STL，你会发现C::B对STL的调试支持很差，其实这并不是Codeblocks的问题，而是GDB本身对STL的支持太差。我们可以看到下图情况： 但是对于一些复杂程序我们有时不得不使用调试观察程序运行情况，然而而STL又是我们编写C++程序一个不可缺少的工具，那我们该如何是好呢？有一个很笨的，但是万能的调试方法，就是输出调试，如果熟练这种调试方法会让我们非常迅速找到BUG，但是对于学习他人程序，以及大多数程序员来说但不调试还是有必要的，所以这里介绍一下怎么用python脚本来支持GDB，从而达到完美支持调试STL的目的。 二、如何在Codeblocks下使用： 1、我们可以在 http://qp-gcc.googlecode.com/files/gdb-7.2.7z （MinGW GDB build with python support, also include wx and stl pretty printer 2010-09-05更新），这个打包文件已经包含了所有需要用到的python的文件，所以你不需要再下载python运行环境。也可以在 http://code.google.com/p/qp-gcc/downloads

随着Xcode 5的发布，LLDB调试器已经取代了GDB，成为了Xcode工程中默认的调试器。它与LLVM编译器一起，带给我们更丰富的流程控制和数据检测的调试功 能。LLDB为Xcode提供了底层调试环境，其中包括内嵌在Xcode IDE中的位于调试区域的控制面板，在这里我们可以直接调用LLDB命令。如图1所示： 图1：位于Xcode调试区域的控制台 在本文中，我们主要整理一下LLDB调试器提供给我们的调试命令，更详细的内容可以查看 The LLDB Debugger 。 LLDB命令结构 在使用LLDB前，我们需要了解一下LLDB的命令结构及语法，这样可以尽可能地挖掘LLDB的潜能，以帮助我们更充分地利用它。 LLDB命令的语法有其通用结构，通常是以下形式的： 1 <command> [<subcommand> [<subcommand>...]] <action> [-options [option-value]] [argument [argument...]]</action></subcommand></subcommand></command> 其中： (命令)和(子命令)：LLDB调试命令的名称。命令和子命令按层级结构来排列：一个命令对象为跟随其的子命令对象创建一个上下文，子命令又为其子命令创建一个上下文，依此类推。 ：我们想在前面的命令序列的上下文中执行的一些操作。

首先强调： 不推荐通过nodejs安装，太麻烦，还容易出错 第一步下载该插件： https://chrome.zzzmh.cn/info?token=nhdogjmejiglipccpnnnanhbledajbpd 直接推荐下载就行 第二步： 解压压缩包 第三步： 打开谷歌浏览器，点击右上角 ==》选择更多工具按钮 ==》选择扩展程序 然后将之前解压的 Vue.js Devtools_5.3.3_chrome.zzzmh.cn.crx 文件拖拽到扩展程序界面，按照对应提示点击确认即可。 来源： CSDN 作者： _CanisLupus 链接： https://blog.csdn.net/qq_42001004/article/details/104694505

1、参考流程 https://flutterchina.club/setup-windows/#更新环境变量 jspang.com/detailed?id=41 2、开发工具 直接上VSCODE，别上Android studio了。 开发和调试均在VSCODE上。 3、仓库地址修改 修改好的工程地址： https://gitee.com/mengfangui113/flutter-demo 4、真机调试 VSCODE命令行下输入： flutter devices 运行flutter程序： flutter run 运行正常： 效果： Flutter环境搭建的确比较复杂。 来源： https://www.cnblogs.com/mengfangui/p/12425181.html

转载：https://segmentfault.com/a/1190000009682735 前言 vue-devtools是一款基于chrome游览器的插件，用于调试vue应用，这可以极大地提高我们的调试效率。接下来我们就介绍一下vue-devtools的安装。 chrome商店直接安装 vue-devtools可以从chrome商店直接下载安装，非常简单，这里就不过多介绍了。不过要注意的一点就是，需要翻墙才能下载。 手动安装 第一步：找到vue-devtools的github项目，并将其clone到本地. vue-devtools git clone https://github.com/vuejs/vue-devtools.git 第二步：安装项目所需要的npm包 npm install //如果太慢的话，可以安装一个cnpm, 然后命令换成 cnpm install 第三步：编译项目文件 npm run build 第四步：添加至chrome游览器 游览器输入地址“chrome://extensions/”进入扩展程序页面，点击“加载已解压的扩展程序...”按钮，选择vue-devtools>shells下的chrome文件夹。 /** *如果看不见“加载已解压的扩展程序...”按钮，则需要勾选“开发者模式”。 */ 到此添加完成，效果图如下： 结语：vue

在程序开发中，调试程序是最频繁的，那使用了webpack后，所有的代码都打包到了一起，这给调试带来了困难，但是webpack在设计时就已经考虑好了这点，它支持生产Source Maps来方便我们的调试。 Source Maps能够提供将压缩文件恢复到源文件原始位置的映射代码的方式，在Chrome和Firefox的开发工具既附带内置的Source Maps的支持。 Source Maps详细学习 在使用webpack时只要通过简单的devtool配置，webapck就会自动给我们生产source maps 文件,map文件是一种对应编译文件和源文件的方法，使调试变得简单。 在配置devtool时，webpack给我们提供了四种选项。 1.source-map:在一个单独文件中产生一个完整且功能完全的 .map 文件（能定位到具体某行某个位置）。这个文件具有最好的source map,但是它会减慢打包速度； 在webpack.config.js中的入口文件上方配置： module.exports = { devtool: 'eval-source-map', //配置调试 entry: "", output: {} } 打包后的结果： 2.cheap-module-source-map:在一个单独的文件中产生一个不带列映射的map（会告诉你具体某行出错，而不能具体到某行某个位置出错。）