Program terminated with signal 6, Aborted,有可能啥原因呢？其中一种原因就是事实上的OOM（虽然/var/log/message中没有标明操作系统kill了进行，应该是进程内部初始化已申请内存时报错了，因为malloc的申请会被OS尽可能延后的分配，所以很有可
内存地址在0x7ff16473d000，相当于140,674,749,157,376（127T965GB（131013GB）处开始，47位最大是128TB，131072GB），如下，也就是在用户空间（0～0x7FFF FFFF FFFF，128GB）快顶部（差59GB）的位置。 因为48bit空间也要满足“两头顶格”的习惯，整个可用地址范围变成了0～0x7FFF FFFF FFFF和0
首先可以确定是ulimit已经都设置为ulimited，所以一定不是内核大小限制的问题。BFD: Warning: /tmp/barry/core.exdoc_usermaint.11 is truncated: expected core file size >, 原因就是程序误写了core文件的文件头。
可变参数宏 1999年的ISO C标准里规定了可变参数宏，语法和函数类似，比如： #define debug(format, ...) fprintf (stderr, format, __VA_ARGS__) 其中的"…"表示可变参数，实际调用时，它们会替代宏体里的__VA_ARGS__。GCC支
除了源码，了解WAL最好的方式是通过pg_waldump入手： [lightdb@lightdb1 bin]$ ./lt_waldump --help lt_waldump decodes and displays LightDB write-ahead logs for debugging. Us
本来vs是没有意见的，实在是vs 2017太大了，又不做windows下开发。从2020.2开始，clion原生支持makefile、cmake则很早就支持，这样对于makefile工程如pg就不再需要通过cmakefile调用makefile。https://isocpp.org/blog/202
文件指针是指向一个FILE的结构体，这个结构体里包括一个文件描述符（在Windows下
信号分成两种： regular signal( 非实时信号 ), 对应的编码值为 [1,31]real time signal 对应的编码值为 [32,64] 编码为 0 的信号 不是有效信号，只用于检查是当前进程否有发送信号的 权限 ，并不真正发送。 线程会有自己的悬挂信号队列 , 并且线程组也有
我们有台测试服务器pro*c/oci应用总是发生各种比较奇葩的现象，就这一台机器会发生，其他几十台都不会发生。 sig 11的原因，内存地址访问越界。各signo的si_code含义可参考http://man7.org/linux/man-pages/man2/sigaction.2.html，在本
visual studio有自带的，可以看MSDN，不过一般来说，我们比较关注linux下的，搜了下，比较好用的应该有gprof和valgrind，先记录，可参考如下： http://blog.csdn.net/clarstyle/article/details/41747817?utm_sourc
春节放假期间，一直在学习c++，越想越发现c++标准之于gcc/vc/boost等实现相当于jsr规范之于sunjdk/ibmjdk/tomcat/weblogic等实现
如同linux下通常要求安装特定版本的libstdc++一样，windows下vc++生成的exe发布时的依赖dll问题，可以参见帖子，http://bbs.csdn.net/topics/391052257，这个帖子应该来说已经很清晰的说明了如何分发的问题。
昨晚，在编译rabbitmq-c时，使用cmake生成vs项目文件时遇到下列错误： CMake Error at C:/Program Files/CMake/share/cmake-3.6/Modules/FindPackageHandleStandardArgs.cmake:148 (messa
调用最简单的JNI没有出错，但是涉及到OCI时就会异常退出，分析后基本确定是OCI 11g中的signal所致，参考ora-24550 signo=6 signo=11解决。 但是这个相同的so库直接被其它c++应用调用就一直正常，但是java通过jni调用就会挂掉，而且很有规律。如果是单个线程循环
最近，在debug core的时候，发现p 变量的时候提示“No symbol "*" in current context”，我们的代码使用-g编译的，经查有可能是下列几个原因或解决方法： 注：make gdb的时候可能会出现/gdb-7.10/missing: line 81: makeinfo
gdb调试程序函数名为问号，什么原因？ http://bbs.chinaunix.net/thread-1823649-1-1.html http://www.bubuko.com/infodetail-1877415.html 其实就是3个原因：源代码和可执行程序版本不一致；没有符号表，这不只是-
总体来说，各个步骤以及版本参考官方文档http://nginx.org/en/docs/howto_build_on_win32.html一点没错，有些细节没说清楚。 To build nginx: Start MSYS bash. Check out nginx sources from the
因为我们整个项目都是使用c++开发的，生成的so足有50M，原来编译一遍要三五分钟，一个针对oracle，一个针对mysql，整个轮回下来这部分就要10来分钟，加上代码上传、翻译，一轮配管打包下来二三十分钟。BOSS有些生气，效率比较低。今天一大早到公司就着手测试。经在本地vmware测试，编译gp
typeid和typeof是c++/gcc编译器的两个关键字，也就是操作符，所以他们根本就不会声明在头文件中。 只不过typeid返回的是type_info，它定义在<typeinfo>头文件中，同时，要使用typeid，就必须先包含该头文件。如下： This header defines type
当gdb的版本低于相应的gcc版本的时候，就会出现debug的时候出现No symbol "*" in current context或者The address where a.out.debug has been loaded is missing等错误，此时需要确保gdb的版本应该在gcc发布之
前一段跟同事聊项目组已有的一些工具，同事讲里面有太多的malloc与memset，对性能的影响比较大，因此今天就在自己的机器上测试了这两个函数，不多说，上数据。测试环境：2.2GHZ、2G内存memset一段大小为1K的buf,每秒有1200万次；10K的buf，每秒有260万次；100K的buf,
这几天在分析一个性能未达预期的功能，使用gperftools cpu profiler生成后，使用pprof格式化的时候，发现pprof出的结果函数名未翻译、为函数地址，如下所示： 每个节点代表一个函数，节点数据格式： Class Name Method Name local (percentage
前一天在测试一个数据导出的时候，发现oci7编译的时候报了一大堆类似"’oparse’未定义的引用问题"，这通常是因为找不到实现库的原因，但是oci相关的库又都是存在的，用oci7的接口就没有问题，找了很久都没找到，于是只能怀疑是oci7的接口c++无法兼容，于是将编译器从g++改成gcc，还是这个
因为项目原因，需要使用到rabbitmq的c客户端库。首先，参见上一篇windows下openssl编译，如果已经使用cmake编译过了，则先delete cache（File-Delete Cache），否则原来的cmake缓存都在了，将仍然会出现原来的错误。 依次点击configire、gene
代码格式化 1、选中代码； 2、ctrl+K； 3、ctrl+F; 显示行号
最近在制作我们系统的发布包时，整理到ftp的时候，发现我们使用的是ssh模式进行文件传输的，而不是RFC 959的ftp，于是查了下，发现存在两种模式的文件传输模式，FTP和SSH。 第一个RFC的FTP协议发布通过网络使用FTP协议（由RFC 959或更高版本）的文件传输始于1980年，FTP提供
map作为最常用的数据结构之一，用的好可以大幅度的提升性能。 更多可参考http://blog.sina.com.cn/s/blog_a9303fd9010195hm.html。
vc获取时间戳的代码如下：
c++ 11开始语言本身和标准库支持并发编程，意味着真正要到编译器从语言和标准库层面开始稳定，估计得到17标准出来、14稳定之后的事情了，根据历史经验，新特性的引入到稳定被广泛采用至少要一个大版本的跨越才能稳定和被大规模production使用。 关于c++ 11之前的两个常用线程库主要是pthre
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
