From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113368 invoked by alias); 27 Nov 2017 02:23:55 -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 113352 invoked by uid 89); 27 Nov 2017 02:23:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 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=H*r:sk:gdb@sou, sk:ablackt, H*r:10.80.135, U*ablacktshirt X-HELO: mail-wm0-f42.google.com Received: from mail-wm0-f42.google.com (HELO mail-wm0-f42.google.com) (74.125.82.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 27 Nov 2017 02:23:53 +0000 Received: by mail-wm0-f42.google.com with SMTP id r68so31945466wmr.1 for ; Sun, 26 Nov 2017 18:23:53 -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:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WfT173p8kXrveh/R2MYHY0hT5zgcRpbi6eiuQ3mz2HU=; b=rPUc0S20ZoFDqLdnDPf7kI1/ZmBw1IoRoN55XH9GJgH+Zyh2O1n6YdyoQUs52AZg4q Qj9/5APAtQ1c8Rr492qi0O+cMIr8dPf8o6LVFzOPlhgxRI/xpdT2bpfw1BBIph/Jx8vK XE1gEY3TxcfWBX/K1j0lQTy3cVPSy+eD73zwvT18wf7H44EtsUQ7DVwIYECIsgwAS0aJ RekKkDWA+zaK2c0w9wZ2DFxxme1dsQ5RdjLmObYAh2mCmkiJeWFWLH/7wEC9rkNbme+H NWjMCdv3jiXOcoM+2Hwf3twDJ1/JXpdkyZbQUVkTso6GAP6abXtLy19aMrYq2WUdl+1V OCfw== X-Gm-Message-State: AJaThX6nA2awXs4QOqUSA9QyDGWcEe3/ZIZZ2skiK3XFTEo8u5BgaXKV vTgXSwDBGFJzARsJ3+ZGMLCER2eh5eaOVRDduw== X-Google-Smtp-Source: AGs4zMZORki2tYfznQ1flSF9KTB1yUd365Rli2GczqXB5mv+kz4I15zpjcooM1t95uqClqA25rqynKOKSh40BwTm7wo= X-Received: by 10.80.225.3 with SMTP id h3mr4579895edl.128.1511749431529; Sun, 26 Nov 2017 18:23:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.135.140 with HTTP; Sun, 26 Nov 2017 18:23:51 -0800 (PST) In-Reply-To: References: From: Yubin Ruan Date: Mon, 27 Nov 2017 02:23:00 -0000 Message-ID: Subject: Re: 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/msg00027.txt.bz2 2017-11-26 17:07 GMT+08:00 Yubin Ruan : > 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... It seems that a process cannot receive any signal when stopped... Yubin