外网崩溃现象: 1.多台物理机中的多个进程消失,而且都是场景进程. 2.core文件都很小,看了 ulimit -a 和 cat proc/pid/limits  (都很正常.看这个是为了以后core文件正常.) 3.场景日志中堆栈信息都是 libc.so.6 (abort 或者 malloc) 4.场景日志中在崩溃堆栈信息的前一条都是某玩家离线打印出来的日志. gdb调试core文件后报错内容如题:Program terminated with signal 6, Aborted. 跟之前的主

近期一直在Windows平台开发cocos-2dx游戏,期间做了一次引擎升级,升级到了3.0正式版本号.Windows平台上表现非常正常,没有出现什么问题. 上周五准备公布一个安卓包,编译非常轻松的就过了,没有花费多少时间,可是安装到手机后,发现执行就崩溃了.没办法仅仅好用模拟机调试,再次吐槽Android的模拟器,真的太他妈慢了,不到万不得已我真的不想再去用它,google真的应该好好整一下了. 好不easy执行起来了,看到崩溃的时候logcat的报错是"unable to load nati

在进行app开发过程中会遇到很多的问题,各种崩溃令人相当头疼.当然,解决bug的能力也体现了一个程序员的水平,现在来说一说开发中经常遇到的崩溃问题吧. 常见崩溃问题: 一是signal SIGABRT, 二是EXC_BAD_ACCESS. 一.signal SIGABRT 出现这样的崩溃一般有两个原因:1. 数组越界 输入: NSArray *array = [NSArray arrayWithObject:"]; NSString *str = [array objectAtIndex:];

前言 虽然大家都不愿意看到程序崩溃,但可能崩溃是每个应用必须面对的现实,既然崩溃已经发生,无法阻挡了,那我们就让它崩也崩得淡定点吧. iOS SDK中提供了一个现成的函数 NSSetUncaughtExceptionHandler  用来做异常处理,但功能非常有限,而引起崩溃的大多数原因如:内存访问错误,重复释放等错误就无能为力了. 因为这种错误它抛出的是Signal,所以必须要专门做Signal处理. 什么是Signal 在计算机科学中,信号(英语:Signals)是Unix.类Unix以及其

什么是Signal 在计算机科学中,信号(英语:Signals)是Unix.类Unix以及其他POSIX兼容的操作系统中进程间通讯的一种有限制的方式.它是一种异步的通知机制,用来提醒进程一个事件已经发生.当一个信号发送给一个进程,操作系统中断了进程正常的控制流程,此时,任何非原子操作都将被中断.如果进程定义了信号的处理函数,那么它将被执行,否则就执行默认的处理函数. 在iOS中就是未被捕获的Objective-C异常(NSException),导致程序向自身发送了SIGABRT信号而崩溃. Si

是因为你在调试的时候主动了结束了程度,如上滑结束了程序

最近在研究QT自带的boxes例子,自己派生一个图形项,但是在运行生成该图形项时程序直接退出了~ Qt Creater调试代码,问题定位如下代码行: 执行1270行时弹出错误消息框: 于是上网查找资料,发现这是个很常见的错误,问题在于调用了野指针! 最后发现是2D贴图类指针m_texture在构造函数中没有初始化,在析构函数中也没有进行释放操作! 修改: 在构造函数中初始化:m_texture = nullptr: 在析构函数中释放:  if (m_texture) delete m_textu

现象:连接电脑可以正常启动程序,不连接电脑启动程序就崩溃. 崩溃信息: BSXPCMessage received error for message: Connection invalid HW kbd: Failed to set (null) as keyboard focus UNNotificationRegistrarConnectionListener connection invalidated UNNotificationSchedulerConnectionListener

摘要: 在android上开发c++应用, crash日志都是汇编码, 很难对应到c++代码中去. 通过此文, 你可以定位到程序崩溃时的C++代码, 精确查找问题. 博客: http://www.cnblogs.com/jhzhu 邮箱: jhzhuustc@gmail.com 作者: 知明所以 时间: 2014-06-20 背景介绍 本文主要内容: 利用android的crash log来对c++开发的android应用进行错误定位. 容易稳定复现的BUG, 一般可以通过断点调试来解决. 如果

Android NDK自从版本R6开始, 提供了一个工具ndk-stack( 在目录{ndk_root}/中 ). 这个工具能自动分析dump下来的crash log, 将崩溃时的调用内存地址和c++代码一行一行对应起来. 执行命令ndk-stack --help Usage: ndk-stack -sym <path> [-dump <path>] -sym Contains full path to the root directory for symbols. -dump C

[转]gdb结合coredump定位崩溃进程 http://blog.sina.com.cn/s/blog_54f82cc201013tk4.html Linux环境下经常遇到某个进程挂掉而找不到原因,我们可以通过生成core file文件加上gdb来定位.   如何产生core file? 我们可以使用ulimit这条命令对core file文件的大小进行设定. 一般默认情况下,core file的大小被设置为了0,这样系统就不dump出core file了. 这时用如下命令进行设置: uli

Android&iOS崩溃堆栈上报 原文地址:http://www.cnblogs.com/songcf/p/4885468.html 通过崩溃捕获和收集,可以收集到已发布应用(游戏)的异常,以便开发人员发现和修改bug,对于提高软件质量有着极大的帮助.在这里总结一下这几天做崩溃捕获的收获. 我们项目使用的是cocos2dx-js,那么要捕获的信息就有以下三点: js脚本语法错误.js调用为定义的native对象(程序不会崩溃) iOS(obj-c)/Android(java)端的未捕获异常导致

通过崩溃捕获和收集,可以收集到已发布应用(游戏)的异常,以便开发人员发现和修改bug,对于提高软件质量有着极大的帮助.本文介绍了iOS和android平台下崩溃捕获和收集的原理及步骤,不过如果是个人开发应用或者没有特殊限制的话,就不用往下看了,直接把友盟sdk(一个统计分析sdk)加入到工程中就万事大吉了,其中的错误日志功能完全能够满足需求,而且不需要额外准备接收服务器. 但是如果你对其原理更感兴趣,或者像我一样必须要兼容公司现有的bug收集系统,那么下面的东西就值得一看了. 要实现崩溃捕获和收

什么是JNI内存泄露,基本的避免方法 : http://www.ibm.com/developerworks/cn/java/j-lo-jnileak/ 最近的课题中需要用到Spark,同组同学负责的算法用c++写的,数据库读取及调用算法用的是java,因此在整合的时候用到了jni. 因为任务需要并行,因此想到了用多线程实现. 程序在单机单线程的情况下运行没问题,当开两个线程的时候就出现了如下错误: # A fatal error has been detected by the Java Ru

文/donglin 虽然大家都不愿意看到程序崩溃,但可能崩溃是每个应用必须面对的现实,既然崩溃已经发生,无法阻挡了,那我们就让它崩也崩得淡定点吧. IOS SDK中提供了一个现成的函数 NSSetUncaughtExceptionHandler 用来做异常处理,但功能非常有限,而引起崩溃的大多数原因如:内存访问错误,重复释放等错误就无能为力了,因为这种错误它抛出的是Signal,所以必须 要专门做Signal处理.在didFinishLaunchingWithOptions 中,加入 代码如下:

api含义:QCoreApplication::processEvents() 将处理所有事件队列中的事件并返回给调用者. 问题描述: 当主线程在某个槽函数里正在执行processEvents时, 刚好有一个能响应此槽函数的信号发送过来了(肯定是其他线程发的信号),  这时就可能会发生可怕的递归, 导致栈溢出崩溃. 原因是processEvents,进入到无尽的递归中. 示例代码: bugThread.h #include <QThread> class BugThread : public

1. 会引起异常的几个原因(主要记录目前遇到过的几个问题) 程序读取了无效的内存地址 堆栈的溢出,比如无限循环导致那段内存溢出,比如把size为20的缓存拷贝到size为10的缓存块等 无法申请到有效的内存 多次删除同一块内存 2. 异常处理 2.1 SEH(Structured Exception Handling) SEH是C语言的异常处理方法,主要使用如下方法处理异常,这个一般用于主动防御性代码中 try { throw 20; } catch (int e) { cout << &qu

Application received signal SIGSEGV (null) ( 0 CoreFoundation 0x2f2dde9b + 154 1 libobjc.A.dylib 0x3963a6c7 objc_exception_throw + 38 2 CoreFoundation 0x2f2dddc5 + 0 3 MyApp 0x1cc7f1 _ZN15CTXAppidConvert10IsMQQAppIdEPKc + 186764 4 libsystem_platform.

虽然大家都不愿意看到程序崩溃,但可能崩溃是每个应用必须面对的现实,既然崩溃已经发生,无法阻挡了,那我们就让它崩也崩得淡定点吧. IOS SDK中提供了一个现成的函数 NSSetUncaughtExceptionHandler 用来做异常处理,但功能非常有限,而引起崩溃的大多数原因如:内存访问错误,重复释放等错误就无能为力了,因为这种错误它抛出的是Signal,所以必须要专门做Signal处理.首先定义一个UncaughtExceptionHandler类,代码如下: #import <Found

在android下面使用jni来调用c++,在开发游戏是非常正常的.但是要调试c++部分却是非常麻烦的问题.如果快速定位崩溃位置呢.NDK提供了一个小工具ndk-stack. 首先,我们先配置环境,把NDK路径和adb的路径配置到环境变量中.如下面: ADBPATH = F:\DevelopTools\adt-bundle-windows-x86_64-20131030\sdk\platform-tools NDKROOT = F:\DevelopTools\android-ndk-r9d Pa

引言     在<I/O的效率比较>中,我们在修改图1程序的BUF_SIZE为8388608时,运行程序出现崩溃,如下图1:          图1. 段错误     一般而言,导致程序段错误的原因如下: 内存访问出错,这类问题的典型代表就是数组越界. 非法内存访问,出现这类问题主要是程序试图访问内核段内存而产生的错误. 栈溢出, Linux默认给一个进程分配的栈空间大小为8M,因此你的数组开得过大的话会出现这种问题.     首先我们先看一下系统默认分配的资源: $ ulimit -acor