linux 多线程信号总结(一)
1. 在多线程环境下，产生的信号是传递给整个进程的，一般而言，所有线程都有机会收到这个信号，进程在收到信号的的线程上下文执行信号处理函数，具体是哪个线程执行的难以获知。也就是说，信号会随机发个该进程的一个线程。
2 signal函数BSD/Linux的实现并不在信号处理函数调用时，恢复信号的处理为默认，而是在信号处理时阻塞此信号，直到信号处理函数返回。其他实现可能在调用信号处理函数时，恢复信号的处理为默认方式，因而需要在信号处理函数中重建信号处理函数为我们定义的处理函数，在这些系统中，较好的方法是使用sigaction来建立信号处理函数。
3 发送信号给进程，哪个线程会收到？APUE说，在多线程的程序中，如果不做特殊的信号阻塞处理，当发送信号给进程时，由系统选择一个线程来处理这个信号。
4 如果进程中，有的线程可以屏蔽了某个信号，而某些线程可以处理这个信号，则当我们发送这个信号给进程或者进程中不能处理这个信号的线程时，系统会将这个信号投递到进程号最小的那个可以处理这个信号的线程中去处理。
5 如果我们同时注册了信号处理函数，同时又用sigwait来等待这个信号，谁会取到信号？经过实验，Linux上sigwait的优先级高。
6 在Linux中的posix线程模型中，线程拥有独立的进程号，可以通过getpid()得到线程的进程号，而线程号保存在pthread_t的值中。而主线程的进程号就是整个进程的进程号，因此向主进程发送信号只会将信号发送到主线程中去。如果主线程设置了信号屏蔽，则信号会投递到一个可以处理的线程中去。
7 当调用SYSTEM函数去执行SHELL命令时，可以放心的阻塞SIGCHLD，因为SYSTEM会自己处理子进程终止的问题。
8 使用sleep()时，要以放心的去阻塞SIGALRM信号，目前sleep函数都不会依赖于ALRM函数的SIGALRM信号来工作。
linux 多线程信号总结(二)
1. 默认情况下，信号将由主进程接收处理，就算信号处理函数是由子线程注册的
2. 每个线程均有自己的信号屏蔽字，可以使用sigprocmask函数来屏蔽某个线程对该信号的响应处理，仅留下需要处理该信号的线程来处理指定的信号。
3. 对某个信号处理函数，以程序执行时最后一次注册的处理函数为准，即在所有的线程里，同一个信号在任何线程里对该信号的处理一定相同
4. 可以使用pthread_kill对指定的线程发送信号
APUE的说法:每个线程都有自己的信号屏蔽字,但是信号的处理是进程中所有的线程共享的,这意味着尽管单个线程可以阻止某些信号,但当线程修改了与某个信号相关的处理行为后,所有的线程都共享这个处理行为的改变。这样如果一个线程选择忽略某个信号，而其他线程可以恢复信号的默认处理行为，或者为信号设置一个新的处理程序，从而可以撤销上述线程的信号选择。
进程中的信号是送到单个线程的，如果信号与硬件故障或者计时器超时有关，该型号就被发送到引起该事件的线程中去，而其他的信号则被发送到任意一个线程。
sigprocmask的行为在多线程的进程中没有定义，线程必须使用pthread_sigmask
总结：一个信号可以被没屏蔽它的任何一个线程处理，但是在一个进程内只有一个多个线程共用的处理函数。......
linux 多线程信号总结(三)
1 Linux 多线程应用中，每个线程可以通过调用pthread_sigmask() 设置本线程的信号掩码。一般情况下，被阻塞的信号将不能中断此线程的执行，除非此信号的产生是因为程序运行出错如SIGSEGV；另外不能被忽略处理的信号SIGKILL 和SIGSTOP 也无法被阻塞。
2 当一个线程调用pthread_create() 创建新的线程时，此线程的信号掩码会被新创建的线程继承。
3 信号安装最好采用sigaction方式，sigaction，是为替代signal 来设计的较稳定的信号处理，signal的使用比较简单。signal(signalNO,signalproc);
不能完成的任务是：1.不知道信号产生的原因；
2.处理信号中不能阻塞其他的信号
而signaction，则可以设置比较多的消息。尤其是在信号处理函数过程中接受信号，进行何种处理。
sigaction函数用于改变进程接收到特定信号后的行为。
4 sigprocmask函数只能用于单线程，在多线程中使用pthread_sigmask函数。
5 信号是发给进程的特殊消息，其典型特性是具有异步性。
6 信号集代表多个信号的集合，其类型是sigset_t。
7 每个进程都有一个信号掩码（或称为信号屏蔽字），其中定义了当前进程要求阻塞的信号集。
8 所谓阻塞，指Linux内核不向进程交付在掩码中的所有信号。于是进程可以通过修改信号掩码来暂时阻塞特定信号的交付，被阻塞的信号不会影响进程的行为直到该信号被真正交付。
9 忽略信号不同于阻塞信号，忽略信号是指Linux内核已经向应用程序交付了产生的信号，只是应用程序直接丢弃了该信号而已。
10 sleep和nanosleep，如果没有在它调用之前设置信号屏蔽字的话，都可能会被信号处理函数打断。参见sleep和nanosleep的mannual。
posted @
2018-05-18 17:02 长戟十三千 阅读(381) |
评论 (0) |
编辑 收藏
摘要: 1. 为什么用volatile? C/C++ 中的 volatile 关键字和 const 对应，用来修饰变量，通常用于建立语言级别的 memory barrier。这是 BS 在 "The C++ Programming Language" 对 volatile 修饰词的说明：A volatile specifier is a hint t...
阅读全文
posted @
2018-05-17 17:16 长戟十三千 阅读(194) |
评论 (0) |
编辑 收藏
摘要: Linux 多线程应用中编写安全的信号处理函数在开发多线程应用时，开发人员一般都会考虑线程安全，会使用 pthread_mutex 去保护全局变量。如果应用中使用了信号，而且信号的产生不是因为程序运行出错，而是程序逻辑需要，譬如 SIGUSR1、SIGRTMIN 等，信号在被处理后应用程序还将正常运行。在编写这类信号处理函数时，应用层面的开发人员却往往忽略了信号处理函数执行的上...
阅读全文
posted @
2018-05-17 17:09 长戟十三千 阅读(208) |
评论 (0) |
编辑 收藏我们在用C/C++语言写程序的时侯，内存管理的绝大部分工作都是需要我们来做的。实际上，内存管理是一个比较繁琐的工作，无论你多高明，经验多丰富，难 免会在此处犯些小错误，而通常这些错误又是那么的浅显而易于消除。但是手工“除虫”（debug），往往是效率低下且让人厌烦的，本文将就"段错误"这个 内存访问越界的错误谈谈如何快速定位这些"段错误"的语句。
下面将就以下的一个存在段错误的程序介绍几种调试方法：
1 dummy_function (void)
2 {
3 unsigned char *ptr = 0x00;
4 *ptr = 0x00;
5 }
6
7 int main (void)
8 {
9 dummy_function ();
10
11 return 0;
12 }
|
作为一个熟练的C/C++程序员，以上代码的bug应该是很清楚的，因为它尝试操作地址为0的内存区域，而这个内存区域通常是不可访问的禁区，当然就会出错了。我们尝试编译运行它:
xiaosuo@gentux test $ ./a.out
段错误
|
果然不出所料，它出错并退出了。
1.利用gdb逐步查找段错误:
这种方法也是被大众所熟知并广泛采用的方法，首先我们需要一个带有调试信息的可执行程序，所以我们加上“-g -rdynamic"的参数进行编译，然后用gdb调试运行这个新编译的程序,具体步骤如下:
xiaosuo@gentux test $ gcc -g -rdynamic d.c
xiaosuo@gentux test $ gdb ./a.out
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) r
Starting program: /home/xiaosuo/test/a.out
Program received signal SIGSEGV, Segmentation fault.
0x08048524 in dummy_function () at d.c:4
4 *ptr = 0x00;
(gdb)
|
哦？！好像不用一步步调试我们就找到了出错位置d.c文件的第4行，其实就是如此的简单。
从这里我们还发现进程是由于收到了SIGSEGV信号而结束的。通过进一步的查阅文档(man 7 signal)，我们知道SIGSEGV默认handler的动作是打印”段错误"的出错信息，并产生Core文件，由此我们又产生了方法二。
2.分析Core文件：
Core文件是什么呢？
| The default action of certain signals is to cause a process to terminate and produce a core dump file, a disk file containing an image of the process's memory at the time of termination. A list of the signals which cause a process to dump core can be found in signal(7). |
以 上资料摘自man page(man 5 core)。不过奇怪了，我的系统上并没有找到core文件。后来，忆起为了渐少系统上的拉圾文件的数量（本人有些洁癖，这也是我喜欢Gentoo的原因 之一），禁止了core文件的生成，查看了以下果真如此，将系统的core文件的大小限制在512K大小，再试:
xiaosuo@gentux test $ ulimit -c
0
xiaosuo@gentux test $ ulimit -c 1000
xiaosuo@gentux test $ ulimit -c
1000
xiaosuo@gentux test $ ./a.out
段错误 (core dumped)
xiaosuo@gentux test $ ls
a.out core d.c f.c g.c pango.c test_iconv.c test_regex.c
|
core文件终于产生了，用gdb调试一下看看吧:
xiaosuo@gentux test $ gdb ./a.out core
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".
warning: Can't read pathname for load map: 输入/输出错误.
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0 0x08048524 in dummy_function () at d.c:4
4 *ptr = 0x00;
|
哇，好历害，还是一步就定位到了错误所在地，佩服一下Linux/Unix系统的此类设计。
接着考虑下去，以前用windows系统下的ie的时侯，有时打开某些网页，会出现“运行时错误”，这个时侯如果恰好你的机器上又装有windows的编译器的话，他会弹出来一个对话框，问你是否进行调试，如果你选择是，编译器将被打开，并进入调试状态，开始调试。
Linux下如何做到这些呢？我的大脑飞速地旋转着，有了，让它在SIGSEGV的handler中调用gdb，于是第三个方法又诞生了:
3.段错误时启动调试:
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <string.h>
void dump(int signo)
{
char buf[1024];
char cmd[1024];
FILE *fh;
snprintf(buf, sizeof(buf), "/proc/%d/cmdline", getpid());
if(!(fh = fopen(buf, "r")))
exit(0);
if(!fgets(buf, sizeof(buf), fh))
exit(0);
fclose(fh);
if(buf[strlen(buf) - 1] == '/n')
buf[strlen(buf) - 1] = '/0';
snprintf(cmd, sizeof(cmd), "gdb %s %d", buf, getpid());
system(cmd);
exit(0);
}
void
dummy_function (void)
{
unsigned char *ptr = 0x00;
*ptr = 0x00;
}
int
main (void)
{
signal(SIGSEGV, &dump);
dummy_function ();
return 0;
}
|
编译运行效果如下:
xiaosuo@gentux test $ gcc -g -rdynamic f.c
xiaosuo@gentux test $ ./a.out
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".
Attaching to program: /home/xiaosuo/test/a.out, process 9563
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7ee4b53 in waitpid () from /lib/libc.so.6
#2 0xb7e925c9 in strtold_l () from /lib/libc.so.6
#3 0x08048830 in dump (signo=11) at f.c:22
#4 <signal handler called>
#5 0x0804884c in dummy_function () at f.c:31
#6 0x08048886 in main () at f.c:38
|
怎么样？是不是依旧很酷？
以上方法都是在系统上有gdb的前提下进行的，如果没有呢？其实glibc为我们提供了此类能够dump栈内容的函数簇，详见/usr/include/execinfo.h（这些函数都没有提供man page，难怪我们找不到），另外你也可以通过gnu的手册 进行学习。
4.利用backtrace和objdump进行分析:
重写的代码如下:
#include <execinfo.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
/* A dummy function to make the backtrace more interesting. */
void
dummy_function (void)
{
unsigned char *ptr = 0x00;
*ptr = 0x00;
}
void dump(int signo)
{
void *array[10];
size_t size;
char **strings;
size_t i;
size = backtrace (array, 10);
strings = backtrace_symbols (array, size);
printf ("Obtained %zd stack frames./n", size);
for (i = 0; i < size; i++)
printf ("%s/n", strings[i]);
free (strings);
exit(0);
}
int
main (void)
{
signal(SIGSEGV, &dump);
dummy_function ();
return 0;
}
|
编译运行结果如下：
xiaosuo@gentux test $ gcc -g -rdynamic g.c
xiaosuo@gentux test $ ./a.out
Obtained 5 stack frames.
./a.out(dump+0x19) [0x80486c2]
[0xffffe420]
./a.out(main+0x35) [0x804876f]
/lib/libc.so.6(__libc_start_main+0xe6) [0xb7e02866]
./a.out [0x8048601]
|
这次你可能有些失望,似乎没能给出足够的信息来标示错误,不急,先看看能分析出来什么吧,用objdump反汇编程序,找到地址0x804876f对应的代码位置:
xiaosuo@gentux test $ objdump -d a.out
|
8048765: e8 02 fe ff ff call 804856c <signal@plt>
804876a: e8 25 ff ff ff call 8048694 <dummy_function>
804876f : b8 00 00 00 00 mov $0x0,%eax
8048774: c9 leave
|
我们还是找到了在哪个函数(dummy_function)中出错的,信息已然不是很完整,不过有总比没有好的啊!
后记:
本文给出了分析"段错误"的几种方法,不要认为这是与孔乙己先生的"回"字四种写法一样的哦,因为每种方法都有其自身的适用范围和适用环境,请酌情使用,或遵医嘱。
posted @
2018-05-17 16:53 长戟十三千 阅读(199) |
评论 (0) |
编辑 收藏http://www.it1352.com/459988.html
posted @
2018-05-17 16:50 长戟十三千 阅读(852) |
评论 (0) |
编辑 收藏Segment fault 之所以能够流行于世，是与Glibc库中基本所有的函数都默认型参指针为非空有着密切关系的。
来自:http://oss.lzu.edu.cn/blog/article.php?uid_7/tid_700.html#comment
背景 最近一段时间在linux下用C做一些学习和开发，但是由于经验不足，问题多多。而段错误就是让我非常头痛的一个问题。不过，目前写一个一千行左右的代码，也很少出现段错误，或者是即使出现了，也很容易找出来，并且处理掉。 那什么是段错误？段错误为什么是个麻烦事？以及怎么发现程序中的段错误以及如何避免发生段错误呢？ 一方面为了给自己的学习做个总结，另一方面由于至今没有找到一个比较全面介绍这个虽然是“FREQUENTLY ASKED QUESTIONS”的问题，所以我来做个抛砖引玉吧。下面就从上面的几个问题出发来探讨一下“Segmentation faults"吧。目录1。什么是段错误？2。为什么段错误这么“麻烦”？3。编程中通常碰到段错误的地方有哪些？4。如何发现程序中的段错误并处理掉？正文1。什么是段错误？下面是来自Answers.com的定义：A segmentation fault (often shortened to segfault) is a particular error condition that can occur during the operation of computer software. In short, a segmentation fault occurs when a program attempts to access a memory location that it is not allowed to access, or attempts to access a memory location in a way that is not allowed (e.g., attempts to write to a read-only location, or to overwrite part of the operating system). Systems based on processors like the Motorola 68000 tend to refer to these events as Address or Bus errors.
Segmentation is one approach to memory management and protection in the operating system. It has been superseded by paging for most purposes, but much of the terminology of segmentation is still used, "segmentation fault" being an example. Some operating systems still have segmentation at some logical level although paging is used as the main memory management policy.
On Unix-like operating systems, a process that accesses invalid memory receives the SIGSEGV signal. On Microsoft Windows, a process that accesses invalid memory receives the STATUS_ACCESS_VIOLATION exception. |
另外，这里有个基本上对照的中文解释，来自http://www.linux999.org/html_sql/3/132559.htm所谓的段错误 就是指访问的内存超出了系统所给这个程序的内存空间，通常这个值是由gdtr来保存的，他是一个48位的寄存器，其中的32位是保存由它指向的gdt表， 后13位保存相应于gdt的下标，最后3位包括了程序是否在内存中以及程序的在cpu中的运行级别,指向的gdt是由以64位为一个单位的表，在这张表中 就保存着程序运行的代码段以及数据段的起始地址以及与此相应的段限和页面交换还有程序运行级别还有内存粒度等等的信息。一旦一个程序发生了越界访 问，cpu就会产生相应的异常保护，于是segmentation fault就出现了 |
通过上面的解释，段错误应该就是访问了不可访问的内存，这个内存区要么是不存在的，要么是受到系统保护的。2。为什么段错误这么麻烦？中国linux论坛有一篇精华帖子《Segment fault 之永远的痛》(http://www.linuxforum.net/forum/gshowflat.php?Cat=&Board=program&Number=193239&page=2&view=collapsed&sb=5&o=all&fpart=1&vc=1)在主题帖子里头，作者这么写道：写程序好多年了，Segment fault 是许多C程序员头疼的提示。指针是好东西，但是随着指针的使用却诞生了这个同样威力巨大的恶魔。
Segment fault 之所以能够流行于世，是与Glibc库中基本所有的函数都默认型参指针为非空有着密切关系的。
不知道什么时候才可以有能够处理NULL的glibc库诞生啊！
不得已，我现在为好多的函数做了衣服，避免glibc的函数被NULL给感染，导致我的Mem访问错误，而我还不知道NULL这个病毒已经在侵蚀我的身体了。
Segment fault 永远的痛...... |
后面有好多网友都跟帖了，讨论了Segmentation faults为什么这么“痛”，尤其是对于服务器程序来说，是非常头痛的，为了提高效率，要尽量减少一些不必要的段错误的“判断和处理”，但是不检查又可能会存在段错误的隐患。 那么如何处理这个“麻烦”呢？ 就像人不可能“完美”一样，由人创造的“计算机语言“同样没有“完美”的解决办法。 我们更好的解决办法也许是： 通过学习前人的经验和开发的工具，不断的尝试和研究，找出更恰当的方法来避免、发现并处理它。对于一些常见的地方，我们可以避免，对于一些“隐藏”的地方，我们要发现它，发现以后就要及时处理，避免留下隐患。 下面我们可以通过具体的实验来举出一些经常出现段错误的地方，然后再举例子来发现和找出这类错误藏身之处，最后处理掉。3。编程中通常碰到段错误的地方有哪些？为了进行下面的实验，我们需要准备两个工具，一个是gcc，一个是gdb我是在ubuntu下做的实验，安装这两个东西是比较简单的sudo apt-get install gcc-4.0 libc6-dev
sudo apt-get install gdb |
好了，开始进入我们的实验，我们粗略的分一下类1）往受到系统保护的内存地址写数据 有些内存是内核占用的或者是其他程序正在使用，为了保证系统正常工作，所以会受到系统的保护，而不能任意访问。例子1：Code:#include <stdio.h> int main(){
int i=0;
scanf("%d",i);
printf("%d\n",i);
return 0;
}
编译和执行一下$ gcc -o segerr segerr.c
$ ./segerr
10
段错误
|
咋一看，好像没有问题哦，不就是读取一个数据然后给输出来吗？下面我们来调试一下，看看是什么原因？$ gcc -g -o segerr segerr.c --加-g选项查看调试信息
$ gdb ./segerr
(gdb) l --用l(list)显示我们的源代码
1 ＃i nclude <stdio.h>
2
3 int
4 main()
5 {
6 int i = 0;
7
8 scanf ("%d", i);
9 printf ("%d\n", i);
10 return 0;
(gdb) b 8 --用b(break)设置断点
Breakpoint 1 at 0x80483b7: file segerr.c, line 8.
(gdb) p i --用p(print)打印变量i的值[看到没，这里i的值是0哦]
$1 = 0
(gdb) r --用r(run)运行，直到断点处
Starting program: /home/falcon/temp/segerr
Breakpoint 1, main () at segerr.c:8
8 scanf ("%d", i); --[试图往地址0处写进一个值]
(gdb) n --用n(next)执行下一步
10
Program received signal SIGSEGV, Segmentation fault.
0xb7e9a1ca in _IO_vfscanf () from /lib/tls/i686/cmov/libc.so.6
(gdb) c --在上面我们接收到了SIGSEGV,然后用c(continue)继续执行
Continuing.
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) quit --退出gdb
|
果然我们“不小心”把&i写成了i而我们刚开始初始化了i为0,这样我们不是试图向内存地址0存放一个值吗？实际上很多情况下，你即使没有初始化为零，默认也可能是0，所以要特别注意。补充：可以通过man 7 signal查看SIGSEGV的信息。$ man 7 signal | grep SEGV
Reformatting signal(7), please wait...
SIGSEGV 11 Core Invalid memory reference
|
例子2：Code:#include <stdio.h> int main(){
char *p;
p = NULL;
*p = 'x';
printf("%c", *p);
return 0;
}很容易发现，这个例子也是试图往内存地址0处写东西。这里我们通过gdb来查看段错误所在的行$ gcc -g -o segerr segerr.c
$ gdb ./segerr
(gdb) r --直接运行，我们看到抛出段错误以后，自动显示出了出现段错误的行，这就是一个找出段错误的方法
Starting program: /home/falcon/temp/segerr
Program received signal SIGSEGV, Segmentation fault.
0x08048516 in main () at segerr.c:10
10 *p = 'x';
(gdb)
|
2）内存越界(数组越界，变量类型不一致等)例子3：Code:#include <stdio.h> int main(){
char test[1];
printf("%c", test[1000000000]);
return 0;
}
这里是比较极端的例子，但是有时候可能是会出现的，是个明显的数组越界的问题
或者是这个地址是根本就不存在的
例子4：
Code:
#include <stdio.h>
int main(){
int b = 10;
printf("%s\n", b);
return 0;
}我们试图把一个整数按照字符串的方式输出出去，这是什么问题呢？由于还不熟悉调试动态链接库，所以我只是找到了printf的源代码的这里声明部分：
int pos =0 ,cnt_printed_chars =0 ,i ;
unsigned char *chptr ;
va_list ap ;
%s格式控制部分：
case 's':
chptr =va_arg (ap ,unsigned char *);
i =0 ;
while (chptr [i ])
{...
cnt_printed_chars ++;
putchar (chptr [i ++]);
}
|
仔 细看看，发现了这样一个问题，在打印字符串的时候，实际上是打印某个地址开始的所有字符，但是当你想把整数当字符串打印的时候，这个整数被当成了一个地 址，然后printf从这个地址开始去打印字符，直到某个位置上的值为\0。所以，如果这个整数代表的地址不存在或者不可访问，自然也是访问了不该访问的 内存——segmentation fault。类似的，还有诸如：sprintf等的格式控制问题比如，试图把char型或者是int的按照%s输出或存放起来，如：Code:#include <stdio.h> #include <string.h>
int main(){
char c='c';
int i=10;
char buf[100];
printf("%s", c); //试图把char型按照字符串格式输出，这里的字符会解释成整数，
//再解释成地址，所以原因同上面那个例子
printf("%s", i); //试图把int型按照字符串输出
memset(buf, 0, 100);
sprintf(buf, "%s", c); 试图把char型按照字符串格式转换
memset(buf, 0, 100);
sprintf(buf, "%s", i);//试图把int型按照字符串转换
}3）其他其实大概的原因都是一样的，就是段错误的定义。但是更多的容易出错的地方就要自己不断积累，不段发现，或者吸纳前人已经积累的经验，并且注意避免再次发生。例如：<1>定义了指针后记得初始化，在使用的时候记得判断是否为NULL<2>在使用数组的时候是否被初始化，数组下标是否越界，数组元素是否存在等<3>在变量处理的时候变量的格式控制是否合理等再举一个比较不错的例子：我在进行一个多线程编程的例子里头，定义了一个线程数组#define THREAD_MAX_NUMpthread_t thread[THREAD_MAX_NUM];用pthread_create创建了各个线程，然后用pthread_join来等待线程的结束刚 开始我就直接等待，在创建线程都成功的时候，pthread_join能够顺利等待各个线程结束，但是一旦创建线程失败，那用pthread_join来 等待那个本不存在的线程时自然会存在访问不能访问的内存的情况，从而导致段错误的发生，后来，通过不断调试和思考，并且得到网络上资料的帮助，找到了上面 的原因和解决办法：在创建线程之前，先初始化我们的线程数组，在等待线程的结束的时候，判断线程是否为我们的初始值如果是的话，说明我们的线程并没有创建成功，所以就不能等拉。否则就会存在释放那些并不存在或者不可访问的内存空间。上面给出了很常见的几种出现段错误的地方，这样在遇到它们的时候就容易避免拉。但是人有时候肯定也会有疏忽的，甚至可能还是会经常出现上面的问题或者其他常见的问题，所以对于一些大型一点的程序，如何跟踪并找到程序中的段错误位置就是需要掌握的一门技巧拉。4。如何发现程序中的段错误？有个网友对这个做了比较全面的总结，除了感谢他外，我把地址弄了过来。文章名字叫《段错误bug的调试》(http://www.cublog.cn/u/5251/showart.php?id=173718),应该说是很全面的。而我常用的调试方法有：1）在程序内部的关键部位输出(printf)信息，那样可以跟踪 段错误 在代码中可能的位置为了方便使用这种调试方法，可以用条件编译指令#ifdef DEBUG和#endif把printf函数给包含起来，编译的时候加上-DDEBUG参数就可以查看调试信息。反之，不加上该参数进行调试就可以。2）用gdb来调试，在运行到段错误的地方，会自动停下来并显示出错的行和行号这 个应该是很常用的，如果需要用gdb调试，记得在编译的时候加上-g参数，用来显示调试信息,对于这个，网友在《段错误bug的调试》文章里创造性的使用 这样的方法，使得我们在执行程序的时候就可以动态扑获段错误可能出现的位置：通过扑获SIGSEGV信号来触发系统调用gdb来输出调试信息。如果加上上 面提到的条件编译，那我们就可以非常方便的进行段错误的调试拉。3）还有一个catchsegv命令通过查看帮助信息，可以看到Catch segmentation faults in programs |
这个东西就是用来扑获段错误的，它通过动态加载器（ld-linux.so）的预加载机制（PRELOAD）把一个事先写好的库（/lib/libSegFault.so）加载上，用于捕捉断错误的出错信息。到这里，“初级总结篇”算是差不多完成拉。欢迎指出其中表达不当甚至错误的地方，先谢过!参考资料[具体地址在上面的文章中都已经给出拉]：1。段错误的定义Ansers.comhttp://www.answers.comDefinition of "Segmentation fault"http://www.faqs.org/qa/qa-673.html2。《什么是段错误》http://www.linux999.org/html_sql/3/132559.htm3。《Segment fault 之永远的痛》http://www.linuxforum.net/forum/gshowflat.php?Cat=&Board=program&Number=193239&page=2&view=collapsed&sb=5&o=all&fpart=4。《段错误bug的调试》http://www.cublog.cn/u/5251/showart.php?id=173718后记虽然感觉没有写什么东西,但是包括查找资料和打字，也花了好些几个小时，不过总结一下也是值得的，欢迎和我一起交流和讨论，也欢迎对文章中表达不当甚至是错误的地方指正一下。 posted @
2018-05-17 16:45 长戟十三千 阅读(334) |
评论 (0) |
编辑 收藏
摘要: 在linux中编程的时候 有时候 try catch 可能满足不了我们的需求。因为碰到类似数组越界 ，非法内存访问之类的 ，这样的错误无法捕获。下面我们介绍一种使用捕获信号实现的异常 用来保证诸如段错误之类的错误发生时程序不会崩溃，而是跳过代码继续执行。首先我们来看看发生段错误之后系统的处理。发生段错误后系统会抛出 SIGSEGV 信号 ，之后 调用默认的信号处理函数 ，产生core文件 ，然后关...
阅读全文
posted @
2018-05-17 16:12 长戟十三千 阅读(1731) |
评论 (0) |
编辑 收藏posted @
2018-05-15 17:47 长戟十三千 阅读(252) |
评论 (0) |
编辑 收藏
摘要: 下面主要从以下方面介绍linux内存管理:进程的内存申请与分配内存耗尽之后OOM申请的内存都在哪？系统回收内存【版权声明】博客内容由罗道文的私房菜拥有版权，允许转载，但请标明原文链接http://luodw.cc/2016/08/13/linux-cache/进程的内存申请与分配之前有篇文章介绍hello world程序是如何载入内存以及是如何申请内存的；我在这，再次说明下；同样，还是先给出进程的...
阅读全文
posted @
2018-05-15 16:53 长戟十三千 阅读(480) |
评论 (0) |
编辑 收藏用户态切换为内核态的三种情况：
- 异常事件： 当CPU正在执行运行在用户态的程序时，突然发生某些预先不可知的异常事件，这个时候就会触发从当前用户态执行的进程转向内核态执行相关的异常事件，典型的如缺页异常。
- 外围设备的中断：当外围设备完成用户的请求操作后，会像CPU发出中断信号，此时，CPU就会暂停执行下一条即将要执行的指令，转而去执行中断信号对应的处理程序，如果先前执行的指令是在用户态下，则自然就发生从用户态到内核态的转换。
系统调用的本质其实也是中断，相对于外围设备的硬中断，这种中断称为软中断。从触发方式和效果上来看，这三种切换方式是完全一样的，都相当于是执行了一个中断响应的过程。但是从触发的对象来看，系统调用是进程主动请求切换的，而异常和硬中断则是被动的。
作者：大海孤了岛
链接：https://www.jianshu.com/p/85e931636f27
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
posted @
2018-05-15 16:13 长戟十三千 阅读(399) |
评论 (0) |
编辑 收藏