From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81044 invoked by alias); 26 Nov 2017 09:07:32 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 81024 invoked by uid 89); 26 Nov 2017 09:07:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=enterprise, H*r:sk:gdb@sou, Enterprise, H*r:10.80.135 X-HELO: mail-wm0-f43.google.com Received: from mail-wm0-f43.google.com (HELO mail-wm0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 26 Nov 2017 09:07:29 +0000 Received: by mail-wm0-f43.google.com with SMTP id x63so28729236wmf.2 for ; Sun, 26 Nov 2017 01:07:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=5g7BqPUK2OLRYC8n9IfW8O2gzYq9z+BoYIS2t+DMbn4=; b=Cp3O6fS/Qo0w4RdqF6lbTv4C+gJlPV3Ha7dNx3eQ01OrPATa+RdelEGL8qWybKyYGv mI0qVvFDR2R9RZjPoV3CaRXiE2nZYSBrfYsnpYNsPjtwXD/vbyOzGECwXdxxe/B3ZpT0 59mpD1dCcuC0jMkoEoKxYm5hEGlRcZ45AhTxg3gbttrmApacoEEtFWzNPimq8Thv3QpR 445lzGW6IBmXEX89oWjQoQOPrtywupY1K9NFOHc9XbxAv3hK0zVW5b4v0btlPFHozv0z f3NiYxoc71m9iuu+xRDqVlVDJyjZJNb56UU/bQLat4cWP0AAOhRW9yHh797XvW+b+V+p 0Yyg== X-Gm-Message-State: AJaThX7htqUs9RC+F7aHP8ND3BfxjEZFqHjeP28CGJcaX+pYfjLVANKD rXHJV8VlYXIb99HVvVi1L4BaerqJ2oqqwQbYbi0O X-Google-Smtp-Source: AGs4zMZgbRQN3iOEcu/0/6XMohC/aq5jIXViSZbqLIA3X+VwI24NQsEnETI7VVQkhitAtIw5gABy61XAqH9kc7QN48s= X-Received: by 10.80.167.228 with SMTP id i91mr20835196edc.20.1511687247046; Sun, 26 Nov 2017 01:07:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.135.140 with HTTP; Sun, 26 Nov 2017 01:07:26 -0800 (PST) From: Yubin Ruan Date: Sun, 26 Nov 2017 09:07:00 -0000 Message-ID: Subject: Why can GDB mask tracee's SIGKILL after attaching To: linux-man Cc: gdb@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg00026.txt.bz2 The signal(7) man page says that **SIGKILL** cannot be caught, blocked, or ignored. But I just observed that after attaching to a process with GDB, I can no longer send **SIGKILL** to that process (similarly, other signal cannot be delivered either). But after I detached and quit GDB, **SIGKILL** is delivered as usual (and the process get killed, eventually). It seems to me that GDB has blocked that signal (on behalf of the tracee) when attaching, and unblocked it when detaching. However, the ptrace(2) man page says: While being traced, the tracee will stop each time a signal is delivered, even if the signal is being ignored. (An exception is **SIGKILL**, which has its usual effect.) So why does it behave this way? Is there anything wrong with the man page or is GDB using any kernel trick? Here is an trivial example for demonstration: #include #include #include #include #include #include #include /* Simple error handling functions */ #define handle_error_en(en, msg) \ do { errno = en; perror(msg); exit(EXIT_FAILURE); } while (0) struct sigaction act; void sighandler(int signum, siginfo_t *info, void *ptr) { printf("Received signal: %d\n", signum); printf("signal originate from pid[%d]\n", info->si_pid); } int main(int argc, char *argv[]) { printf("Pid of the current process: %d\n", getpid()); memset(&act, 0, sizeof(act)); act.sa_sigaction = sighandler; act.sa_flags = SA_SIGINFO; sigaction(SIGQUIT, &act, NULL); while(1) { ; } return 0; } If you try to kill this program using **SIGKILL** (i.e., using "kill -KILL ${pid}"), it will die as expected. If you try to send it **SIGQUIT** (i.e., using "kill -QUIT ${pid}"), those "printf" statements get executed, as expected. However, if you have attached it with GDB before sending it signal, nothing will happen: $ ##### in shell 1 ##### $ gdb (gdb) attach ${pid} (gdb) /* now that gdb has attached successfully, in another shell: */ $ #### in shell 2 #### $ kill -QUIT ${pid} # nothing happen $ kill -KILL ${pid} # again, nothing happen! /* now gdb detached */ ##### in shell 1 #### (gdb) quit /* the process will receive **SIGKILL** */ ##### in shell 2 #### $ Killed # the tracee receive **SIGKILL** eventually... FYI, I am using a CentOS-6u3 and $ uname -r $ 2.6.32_1-16-0-0 My GDB version is: $ gdb --version $ GNU gdb (GDB) Red Hat Enterprise Linux (7.2-56.el6) ..... and my GCC version is: $ gcc --version $ gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-19.el6)`. ..... Any idea will be appreciated ;-) Yubin