当前位置: 技术问答>linux和unix
大侠们来一下,真心求教个问题,急~~
来源: 互联网 发布时间:2017-02-17
本文导语: 代码如下: #include #include #include #include void test(pid_t pid) { while(1) { sleep(1); } } void test1(pid_t pid) { while(1) { sleep(1); } } int main() { pid_t pid = 0; int ret = 0; pid = fork(); if (pid == ...
代码如下:
#include
#include
#include
#include
void test(pid_t pid)
{
while(1) {
sleep(1);
}
}
void test1(pid_t pid)
{
while(1) {
sleep(1);
}
}
int main()
{
pid_t pid = 0;
int ret = 0;
pid = fork();
if (pid == 0) {
//setsid();
test1(pid);
} else if (pid > 0)
{
printf("This is the parent process! my id=%d ,child process id = %dn", getpid(),pid);
test(pid);
} else {
printf("fork errorn");
}
return 1;
}
gdb对子进程进行调试:
aven@dolphin-j:~> ./ctrl_c_test &
[1] 6537
This is the parent process! my id=6537 ,child process id = 6538
aven@dolphin-j:~> gdb attach 6538
GNU gdb (GDB) SUSE (7.0-0.4.16)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
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-suse-linux".
For bug reporting instructions, please see:
...
attach: No such file or directory.
Attaching to process 6538
Reading symbols from /home/aven/ctrl_c_test...done.
Reading symbols from /lib64/libc.so.6...Missing separate debuginfo for /lib64/libc.so.6
Try: zypper install -C "debuginfo(build-id)=a41ac0b0b7cd60bd57473303c2c3de08856d2e06"
(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2
Try: zypper install -C "debuginfo(build-id)=17c088070352d83e7afc43d83756b00899fd37f0"
(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00007f9b618bf060 in __nanosleep_nocancel () from /lib64/libc.so.6
(gdb) c
Continuing.
^C^C^C^C^Z
gdb attach父进程则能够正常退出。ctrl+c只能用于前台的进程,我不知道此处是否是因为gdb attach的时候不能把子进程拿到前台来运行。
另外,在子进程中用setsid()切断和现在进程组(作业)的关系,或者新开一个session(窗口)来gdb调试子进程,都能够正常退出。什么原因?
#include
#include
#include
#include
void test(pid_t pid)
{
while(1) {
sleep(1);
}
}
void test1(pid_t pid)
{
while(1) {
sleep(1);
}
}
int main()
{
pid_t pid = 0;
int ret = 0;
pid = fork();
if (pid == 0) {
//setsid();
test1(pid);
} else if (pid > 0)
{
printf("This is the parent process! my id=%d ,child process id = %dn", getpid(),pid);
test(pid);
} else {
printf("fork errorn");
}
return 1;
}
gdb对子进程进行调试:
aven@dolphin-j:~> ./ctrl_c_test &
[1] 6537
This is the parent process! my id=6537 ,child process id = 6538
aven@dolphin-j:~> gdb attach 6538
GNU gdb (GDB) SUSE (7.0-0.4.16)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
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-suse-linux".
For bug reporting instructions, please see:
...
attach: No such file or directory.
Attaching to process 6538
Reading symbols from /home/aven/ctrl_c_test...done.
Reading symbols from /lib64/libc.so.6...Missing separate debuginfo for /lib64/libc.so.6
Try: zypper install -C "debuginfo(build-id)=a41ac0b0b7cd60bd57473303c2c3de08856d2e06"
(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2
Try: zypper install -C "debuginfo(build-id)=17c088070352d83e7afc43d83756b00899fd37f0"
(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00007f9b618bf060 in __nanosleep_nocancel () from /lib64/libc.so.6
(gdb) c
Continuing.
^C^C^C^C^Z
gdb attach父进程则能够正常退出。ctrl+c只能用于前台的进程,我不知道此处是否是因为gdb attach的时候不能把子进程拿到前台来运行。
另外,在子进程中用setsid()切断和现在进程组(作业)的关系,或者新开一个session(窗口)来gdb调试子进程,都能够正常退出。什么原因?
|
啊,子进程不是已经脱离终端了么,ctrl+c是发送给前台进程组的,而且子进程不仅不再前台进程组,也不在那个会话里了,按道理说必须kill -9 去杀子进程。
|
子进程继承了父进程的进程组ID,如果终端发送的信号其父进程接收到了,子进程也应该会接收到的,理论上子进程也应该终止的
用子进程重新创建了一个会话,这个时候终端发送的信号发送给子进程,子进程就可以终止了,这么说上中情况子进程并没有收到终端发送的终止信号。 不可能啊! 矛盾啊! 是不是你的分析方法有问题。。。
用子进程重新创建了一个会话,这个时候终端发送的信号发送给子进程,子进程就可以终止了,这么说上中情况子进程并没有收到终端发送的终止信号。 不可能啊! 矛盾啊! 是不是你的分析方法有问题。。。