在Linux中调试段错误(core dumped)

在作比赛的时候经常遇到段错误, 但是一般都采用的是printf打印信息这种笨方法,而且定位bug比较慢,今天尝试利用gdb工具调试段错误.
段错误(core dumped)一般都是数组索引位置不对,或者是数组越界等问题造成,在Linux环境下编程应该很容易就会遇到.

GDB调试的具体流程

查阅资料发现几个讲Core dump的具体方法:

什么是段错误Segmentation fault (core dumped)

段错误一般是指程序尝试访问它不被允许访问的内存地址,可能会被一下情况导致:
- 试图访问(dereference)一个空指针, 系统不允许访问地址为0的内存空间;
- 试图访问一个不在自己内存访问范围内的一个指针;
- 在C++程序中, 一个类的vtable(虚指针的列表)被占用, 而且指向了一个错误的地方, 导致程序试图去执行一个没有运行权限的地址;
- 未内存对齐的程序访问也可能导致段错误.

valgrind简单工具进行调试

valgrind可以跟踪程序的一些堆栈信息, 使用之前必须利用sudo apt-get install valgrind进行安装该命令行工具.
然后通过valgrind -v 可执行程序名字追踪有问题的二进制可执行程序.
下面是段错误程序的显示结果:

$ valgrind -v ./bin/CodeCraft-2019

==19578== Memcheck, a memory error detector

==19578== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.

==19578== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info

==19578== Command: ./bin/CodeCraft-2019

==19578==

--19578-- Valgrind options:

--19578--    -v

--19578-- Contents of /proc/version:

--19578--   Linux version 4.15.0-46-generic (buildd@lgw01-amd64-038) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #49-Ubuntu SMP Wed Feb 6 09:33:07 UTC 2019

--19578--

--19578-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-rdtscp-sse3-avx

--19578-- Page sizes: currently 4096, max supported 4096

--19578-- Valgrind library directory: /usr/lib/valgrind

--19578-- Reading syms from /usrdata/applications/huawei2019/03-28-01-coredump/bin/CodeCraft-2019

--19578-- Reading syms from /lib/x86_64-linux-gnu/ld-2.27.so

--19578--   Considering /lib/x86_64-linux-gnu/ld-2.27.so ..

--19578--   .. CRC mismatch (computed 1b7c895e wanted 2943108a)

--19578--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.27.so ..

--19578--   .. CRC is valid

--19578-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux

--19578--   Considering /usr/lib/valgrind/memcheck-amd64-linux ..

--19578--   .. CRC mismatch (computed c25f395c wanted 0a9602a8)

--19578--    object doesn't have a symbol table

--19578--    object doesn't have a dynamic symbol table

--19578-- Scheduler: using generic scheduler lock implementation.

--19578-- Reading suppressions file: /usr/lib/valgrind/default.supp

==19578== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-19578-by-jl-on-???

==19578== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-19578-by-jl-on-???

==19578== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-19578-by-jl-on-???

==19578==

==19578== TO CONTROL THIS PROCESS USING vgdb (which you probably

==19578== don't want to do, unless you know exactly what you're doing,

==19578== or are doing some strange experiment):

==19578==   /usr/lib/valgrind/../../bin/vgdb --pid=19578 ...command...

==19578==

==19578== TO DEBUG THIS PROCESS USING GDB: start GDB like this

==19578==   /path/to/gdb ./bin/CodeCraft-2019

==19578== and then give GDB the following command

==19578==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=19578

==19578== --pid is optional if only one valgrind process is running

==19578==

--19578-- REDIR: 0x401f2f0 (ld-linux-x86-64.so.2:strlen) redirected to 0x58060901 (???)

--19578-- REDIR: 0x401f0d0 (ld-linux-x86-64.so.2:index) redirected to 0x5806091b (???)

--19578-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so

--19578--   Considering /usr/lib/valgrind/vgpreload_core-amd64-linux.so ..

--19578--   .. CRC mismatch (computed 4b63d83e wanted 670599e6)

--19578--    object doesn't have a symbol table

--19578-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so

--19578--   Considering /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so ..

--19578--   .. CRC mismatch (computed a4b37bee wanted 8ad4dc94)

--19578--    object doesn't have a symbol table

==19578== WARNING: new redirection conflicts with existing -- ignoring it

--19578--     old: 0x0401f2f0 (strlen              ) R-> (0000.0) 0x58060901 ???

--19578--     new: 0x0401f2f0 (strlen              ) R-> (2007.0) 0x04c32db0 strlen

--19578-- REDIR: 0x401d360 (ld-linux-x86-64.so.2:strcmp) redirected to 0x4c33ee0 (strcmp)

--19578-- REDIR: 0x401f830 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x4c374f0 (mempcpy)

--19578-- Reading syms from /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25

--19578--    object doesn't have a symbol table

--19578-- Reading syms from /lib/x86_64-linux-gnu/libgcc_s.so.1

--19578--    object doesn't have a symbol table

--19578-- Reading syms from /lib/x86_64-linux-gnu/libc-2.27.so

--19578--   Considering /lib/x86_64-linux-gnu/libc-2.27.so ..

--19578--   .. CRC mismatch (computed b1c74187 wanted 042cc048)

--19578--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.27.so ..

--19578--   .. CRC is valid

--19578-- Reading syms from /lib/x86_64-linux-gnu/libm-2.27.so

--19578--   Considering /lib/x86_64-linux-gnu/libm-2.27.so ..

--19578--   .. CRC mismatch (computed 7feae033 wanted b29b2508)

--19578--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libm-2.27.so ..

--19578--   .. CRC is valid

--19578-- REDIR: 0x547bc70 (libc.so.6:memmove) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547ad40 (libc.so.6:strncpy) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547bf50 (libc.so.6:strcasecmp) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547a790 (libc.so.6:strcat) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547ad70 (libc.so.6:rindex) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547d7c0 (libc.so.6:rawmemchr) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547bde0 (libc.so.6:mempcpy) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547bc10 (libc.so.6:bcmp) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547ad00 (libc.so.6:strncmp) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547a800 (libc.so.6:strcmp) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547bd40 (libc.so.6:memset) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x54990f0 (libc.so.6:wcschr) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547aca0 (libc.so.6:strnlen) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547a870 (libc.so.6:strcspn) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547bfa0 (libc.so.6:strncasecmp) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547a840 (libc.so.6:strcpy) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547c0e0 (libc.so.6:memcpy@@GLIBC_2.14) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547ada0 (libc.so.6:strpbrk) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547a7c0 (libc.so.6:index) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547ac70 (libc.so.6:strlen) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x54856c0 (libc.so.6:memrchr) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547bff0 (libc.so.6:strcasecmp_l) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547bbe0 (libc.so.6:memchr) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x5499eb0 (libc.so.6:wcslen) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547b050 (libc.so.6:strspn) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547bf20 (libc.so.6:stpncpy) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547bef0 (libc.so.6:stpcpy) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547d7f0 (libc.so.6:strchrnul) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x547c040 (libc.so.6:strncasecmp_l) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)

--19578-- REDIR: 0x548e330 (libc.so.6:__strrchr_sse2) redirected to 0x4c32790 (__strrchr_sse2)

--19578-- REDIR: 0x5474070 (libc.so.6:malloc) redirected to 0x4c2faa0 (malloc)

--19578-- REDIR: 0x548e620 (libc.so.6:__strlen_sse2) redirected to 0x4c32d30 (__strlen_sse2)

--19578-- REDIR: 0x556cfc0 (libc.so.6:__memcmp_sse4_1) redirected to 0x4c35d50 (__memcmp_sse4_1)

--19578-- REDIR: 0x5486e70 (libc.so.6:__strcmp_sse2_unaligned) redirected to 0x4c33da0 (strcmp)

Begin

--19578-- REDIR: 0x5498440 (libc.so.6:__mempcpy_sse2_unaligned) redirected to 0x4c37130 (mempcpy)

please input args: carPath, roadPath, crossPath, answerPath

--19578-- REDIR: 0x5498870 (libc.so.6:__memset_sse2_unaligned) redirected to 0x4c365d0 (memset)

--19578-- REDIR: 0x5474950 (libc.so.6:free) redirected to 0x4c30cd0 (free)

==19578==

==19578== HEAP SUMMARY:

==19578==     in use at exit: 0 bytes in 0 blocks

==19578==   total heap usage: 2 allocs, 2 frees, 73,728 bytes allocated

==19578==

==19578== All heap blocks were freed -- no leaks are possible

==19578==

==19578== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

==19578== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

怎么才能获得core dump文件

一个core dump文件是程序运行时的一份内存拷贝, 通过这个文件可以调试程序找到出bug的地方;
当程序程序出现了段错误时, Linux内核会根据配置情况将一个core dump文件写入到硬盘中.
Linux用ulimit设置连接数的最大值, ulimit只能做临时修改,重启后失效:
- ulimit -c 设置core文件的最大值, 单位为区块;
- ulimit -a 显示目前资源限制的设定.
- 利用ulimit -c unlimited将core文件设置为无限大.
不能产生core文件的原因:
- 没有足够内存空间;
- 禁用了core文件的创建;
- 设置一个进程当前目录没有写文件的的权限;
利用命令sudo sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t设置内核产生core文件的形式和位置, 放于/tmp目录并且显示时间戳.
- 当程序出现段错误的时候, linux内核会自动地在/tmp目录保存一个core文件.
利用cat /proc/PID/limit也可以显示一个进程中的core文件的大小限制.
kernel.core_pattern表示coredumps文件放于什么地方,它是一个内核参数,可以通过sysctl进行查看和进行控制:
- sysctl -a表示查看内核的所有参数, 或使用sysctl kernel.core_pattern显示kernel.core_pattern的参数.

通过GDB工具对生成的core文件进行回溯追踪

通过命令gdb -c my_core_file打开一个名为my_core_file的文件.
调试我的coredump的程序结果如下:

sudo gdb -c /tmp/core-CodeCraft-2019.23637.jl.1554030516

GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show copying"

and "show warranty" for details.

This GDB was configured as "x86_64-linux-gnu".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".

Type "apropos word" to search for commands related to "word".

[New LWP 23637]

Core was generated by `./bin/CodeCraft-2019 ../1-map-training-1/car.txt ../1-map-training-1/road.txt .'.

Program terminated with signal SIGSEGV, Segmentation fault.

#0  0x0000556393da88ad in ?? ()

(gdb)

可以看到, 该程序在执行过程中接收到了一个SIGSEGV信号, 该信号表示一个进程执行了一个无效的内存引用, 或发生了段错误.
然后在gdb工具中不停的bt找到出现段错误在程序的多少行和真正引起段错误的原因.
- bt的含义是backtrace, 列出调用栈.
- gdb调试中常用的几个命令参数:
  - attach用GDB调试一个正在运行中的进程gdb <program> PID;
  - br用来设置断点, br filename:line_num,br namespace::classname::func_name;
  - n:单步跳过, s:单步进行;
  - finish:执行到函数return返回的地方;
  - list:列出当前位置之后的10行代码;list line_number列出line_number之后的十行代码;
  - info locals列出当前函数的局部变量;
  - p var_打印变量值;
  - info breakpoints列出所有断点;
  - delete breakpoints删除所有断点;
  - delete breakpoints id删除编号为id的断点;
  - disable/enable breakpoints id禁用/启动断点;
  - break ... if ...条件中断;
我的程序执行bt后发现有很多问号, 这是因为gdb没有加载我程序库的信息, 编译的时候需要加上-g选项:

(gdb) bt

#0  0x0000556393da88ad in ?? ()

#1  0x00000009b6f194c0 in ?? ()

#2  0x00005563b686d1b0 in ?? ()

#3  0x00005563b688abe0 in ?? ()

#4  0x00007ffe22b8c070 in ?? ()

#5  0x00005563b5f36460 in ?? ()

#6  0x0000000000002bf9 in ?? ()

#7  0x0000000000000004 in ?? ()

#8  0x00005563b718a580 in ?? ()

#9  0x0000000000000020 in ?? ()

#10 0x00007ffe22b8c510 in ?? ()

#11 0x00007ffe22b8bf50 in ?? ()

#12 0x00005563b6a2ffd0 in ?? ()

#13 0x00007ffe22b8bf50 in ?? ()

#14 0x0000000000000008 in ?? ()

#15 0x00005563b6a30004 in ?? ()

#16 0x00007ffe22b8c450 in ?? ()

#17 0x00007ffe22b8c590 in ?? ()

#18 0x0000556393dabd1e in ?? ()

#19 0x00007f1b3f2da1f0 in ?? ()

#20 0x0000556393dabcd2 in ?? ()

#21 0x00007ffe22b8c610 in ?? ()

#22 0x00007ffe22b8bf00 in ?? ()

#23 0x00007ffe22b8c550 in ?? ()

#24 0x00007ffe22f747d0 in ?? ()

#25 0x00007ffe22b8c220 in ?? ()

#26 0x00007ffe22b8c200 in ?? ()

#27 0x0000000000000032 in ?? ()

#28 0x00007ffe22b8c470 in ?? ()

#29 0x00007ffe22b8c530 in ?? ()

#30 0x00007ffe22b8c070 in ?? ()

#31 0x00007ffe22b8c4f0 in ?? ()

#32 0x00007ffe22b8c510 in ?? ()

#33 0x00000000000211e0 in ?? ()

#34 0x00007ffe22b8c5b0 in ?? ()

#35 0x0000000022b8c490 in ?? ()

#36 0x0000000000000198 in ?? ()

#37 0x00007ffe22b8c490 in ?? ()

#38 0x00007ffe22b8c630 in ?? ()

#39 0x00007ffe22b8befc in ?? ()

#40 0x00003d2400000005 in ?? ()

#41 0x0000000000000000 in ?? ()

在gdb中执行symbol-file 共享动态库的路径进行加载gdb调试时的动态库搜索路径.
- ldd命令可以列出一个二进制文件的依赖关系.
- 利用set solib-search-path进行寻找依赖库.

#0  0x0000556393da88ad in ?? ()

#1  0x00000009b6f194c0 in ?? ()

#2  0x00005563b686d1b0 in ?? ()

#3  0x00005563b688abe0 in ?? ()

#4  0x00007ffe22b8c070 in ?? ()

#5  0x00005563b5f36460 in ?? ()

#6  0x0000000000002bf9 in ?? ()

#7  0x0000000000000004 in void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag) [clone .isra.44] ()

#8  0x00007ffe22b8c510 in ?? ()

#9  0x00007ffe22b8bf50 in ?? ()

#10 0x00005563b6a2ffd0 in ?? ()

#11 0x00007ffe22b8bf50 in ?? ()

#12 0x0000000000000008 in void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag) [clone .isra.44] ()

#13 0x0000556393dabd1e in ?? ()

#14 0x00007f1b3f2da1f0 in ?? ()

#15 0x0000556393dabcd2 in ?? ()

#16 0x00007ffe22b8c610 in ?? ()

#17 0x00007ffe22b8bf00 in ?? ()

#18 0x00007ffe22b8c550 in ?? ()

#19 0x00007ffe22f747d0 in ?? ()

#20 0x00007ffe22b8c220 in ?? ()

#21 0x00007ffe22b8c200 in ?? ()

#22 0x0000000000000032 in void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag) [clone .isra.44] ()

#23 0x00000000000211e0 in ?? ()

#24 0x00007ffe22b8c5b0 in ?? ()

#25 0x0000000022b8c490 in ?? ()

Backtrace stopped: Cannot access memory at address 0x195

最后的结果gdb调试结果为:

[New LWP 5070]

Core was generated by `8, 6238, 6768, 6414, 5857, 6219, 6774, 5642, 5099, 6080)

(gdb) frame 0

#0  0x00007fa69aa8f17c in ___vsnprintf_chk (s=0x7ffcb1275ffa ", 5347"<error: Cannot access memory at address 0x7ffcb1276000>, maxlen=<optimized out>,

    flags=1, slen=<optimized out>, format=0x55e0aef3a657 ", %d", args=args@entry=0x7ffcb0e28c00) at vsnprintf_chk.c:66

66	in vsnprintf_chk.c

(gdb) frame 1

#1  0x00007fa69aa8f095 in ___snprintf_chk (s=<optimized out>, maxlen=<optimized out>, flags=<optimized out>, slen=<optimized out>,

    format=<optimized out>) at snprintf_chk.c:34

34	snprintf_chk.c: No such file or directory.

(gdb) frame 2

#2  0x000055e0aef2ee70 in writeResult(std::vector<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > > const&, std::vector<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > >&, std::unordered_map<int, int, std::hash<int>, std::equal_to<int>, std::allocator<std::pair<int const, int> > >&, char*, int) ()

(gdb) frame 3

#3  0x000055e0aef35e5f in scheduling(std::vector<Vehicle, std::allocator<Vehicle> >&, std::vector<Road, std::allocator<Road> >&, std::vector<Cross, std::allocator<Cross> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) ()

(gdb) frame 4

#4  0x35202c3536303620 in ?? ()

以上结果说明在writeResult函数中出现了段错误.
利用thread apply all bt full查看每个线程在堆栈中的使用情况.
GDB过程中最重要的几个指令为:

0. gdb core-CodeCraft-2019.5070.jl.1554081713

1. set solib-absolute-prefix /

2. set solib-search-path /

3. file 可执行文件

4. core-file core-CodeCraft-2019.5070.jl.1554081713

5. frame 2

在Linux中调试段错误(core dumped)的更多相关文章

mysql 段错误 (core dumped)
一直使用好好的mysql命令,突然今天抽风,无论使用任何mysql选项都报“段错误 (core dumped)”,以为是mysqld程序出问题了,所以我尝试重启,因为我的环境上是多实例,用了mysql ...
linux驱动调试--段错误之oops信息分析
linux驱动调试--段错误之oops信息分析 http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=29401328&id= ...
Linux下调试段错误 (gdb,core,ulimit)
Linux环境下经常遇到某个进程挂掉而找不到原因,我们可以通过生成core file文件加上gdb来定位. (1)首先在makefile中要增加编译调试选项 -g,才可以利用下面的gdb来调试 gc ...
coreseek 段错误 (core dumped) 问题
coreseek建立索引出现上面问题经过测试发现有下面几个原因: 1. 分词配置文件不存在 uni.lib 2. uni.lib配置文件格式不正确
linux ulimit的使用，如何产生core文件，调试段错误
---恢复内容开始--- 下面先简单介绍下ulimit命令: 1. limit -a 可以查看系统各种资源的限制,如: core文件大小,数据段的大小等. $ ulimit -a core file ...
Linux环境下段错误的产生原因及调试方法小结（转）
最近在Linux环境下做C语言项目,由于是在一个原有项目基础之上进行二次开发,而且项目工程庞大复杂,出现了不少问题,其中遇到最多.花费时间最长的问题就是著名的“段错误”(Segmentation F ...
Linux环境下段错误的产生原因及调试方法小结
转载自http://www.cnblogs.com/panfeng412/archive/2011/11/06/2237857.html 最近在Linux环境下做C语言项目,由于是在一个原有项目基础之 ...
【转】【调试技巧】Linux环境下段错误的产生原因及调试方法小结
本文转自:http://www.cnblogs.com/panfeng412/archive/2011/11/06/segmentation-fault-in-linux.html 1. 段错误是什么 ...
Linux环境下段错误的产生原因及调试方法小结【转】
转自:http://www.cnblogs.com/panfeng412/archive/2011/11/06/2237857.html 最近在Linux环境下做C语言项目,由于是在一个原有项目基础之 ...

随机推荐

【前端安全】JavaScript防http劫持与XSS
作为前端,一直以来都知道HTTP劫持与XSS跨站脚本(Cross-site scripting).CSRF跨站请求伪造(Cross-site request forgery).但是一直都没有深入研究过 ...
MySQL（二）
一.外键外键是设置当前表中的某一列与别一数据表中的主键列关联.主要目的是控制与外键表中的数据,保持数据一致性,完整性,也就是说:当前表中这一列的数据必须是关联外键列中的某一数据,而且相关联的两个数据 ...
php验证手机号码
大家都应该有这个常识,中国的手机号码都是以数字“1”开头,然后利用“0~9”10个数字组成的11位数字组合,那么我们的验证规则肯定要根据这个思路来写. 根据上面的简单思路,我们便可以写下以下的验证代码 ...
函数 swift
func add(a:Int,b:Int)->Int { return a+b }
然爸读书笔记（2013-4）----打造facebook
扎克伯格的真实一面 (1)在公司内部知无不言,扎克伯格在公司内部问答时间.尽可能回答员工的任何问题,保持足够的透明度. (2)员工只有做到对外守口如瓶,我们才能做到对内知无不言. (3)faceboo ...
delphi xe5 android 开发数据访问server端(一)
第一篇我们破解并安装了xe5 第二篇我们搭建了开发环境接下来我们开发一个三层的android程序建立一个webservices stand-alone vcl application 作为手机访 ...
Struts2中拦截器的使用与配置
一,拦截器是什么? 拦截器是在Action执行之前和之后执行的代码,是一个类似于过滤器的类: 二,拦截器的作用拦截器拦截Action的请求,在Action之前或之后实现某项功能: 三,拦截器的特点 ...
laravel 队列发送邮件
批量处理任务的场景在我们开发中是经常使用的,比如邮件群发,消息通知,短信,秒杀等等,我们需要将这个耗时的操作放在队列中来处理,从而大幅度缩短Web请求和相应的时间.下面讲解下Laravel中队列的使用 ...
安装fftw到window（vs2010）及使用fftw库函数实现4096点fft变换计算
Windows下FFTW库的安装: 1. 从网站http://www.fftw.org/install/windows.html上下载最新的预编译文件: 32-bit version: fftw ...
(转)Ubuntu init启动流程分析
原文 upstart homepage 现行的Linux distros主流的有两种init方式:一种是广为流传的System V initialization,它来源于Unix并且至今仍被各种Lin ...