From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 667 invoked by alias); 6 Feb 2009 05:16:57 -0000 Received: (qmail 657 invoked by uid 22791); 6 Feb 2009 05:16:55 -0000 X-SWARE-Spam-Status: No, hits=-0.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_73,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from rv-out-0708.google.com (HELO rv-out-0708.google.com) (209.85.198.245) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Feb 2009 05:16:50 +0000 Received: by rv-out-0708.google.com with SMTP id b17so590204rvf.48 for ; Thu, 05 Feb 2009 21:16:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.110.92.8 with SMTP id p8mr1963322tib.10.1233897407886; Thu, 05 Feb 2009 21:16:47 -0800 (PST) In-Reply-To: <329369.85710.qm@web36204.mail.mud.yahoo.com> References: <329369.85710.qm@web36204.mail.mud.yahoo.com> Date: Fri, 06 Feb 2009 05:16:00 -0000 Message-ID: Subject: Re: gdb internal error SIGINT/SIGSTOP From: teawater To: paawan1982@yahoo.com Cc: gdb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2009-02/txt/msg00057.txt.bz2 Hi Paawan, Sorry to understand your meaning late. I think I am clear your meaning now. :) gdb check if inferior stop. inferior stop by breakpoint or something. gdb send sig. I try to send a sig to a inferior that stop by breakpoint. It exec OK except it stop by this sig after it continue. So, maybe you can use non-block wait deal with it. By the way, in inferior fly mode, I think user like to know inferior stop by breakpoint at once sometime. Maybe you need do something on it. Thanks, Hui On Fri, Feb 6, 2009 at 00:22, paawan oza wrote: > > Hi Hui, > > of course I would not like to get 2 sigs. > I completely understood what you said. : ) > > before sending SIGINT, check whether any other signal is pending !!! > correct ? > > I am doing exactly the same. > > but do you agree, we can not do folloing two instructions atomically > 1) sending SIGINT > 2) check the status... > > between step 1 and 2 gdb gets scheduled out and.....process gets schedules in and it hits breakpoint and and during kernel delivers SIGINT to it. > > thats is how gdb has got two signals. > > Regards, > ..Paawan. > > > > > > --- On Thu, 2/5/09, teawater wrote: > > > From: teawater > > Subject: Re: gdb internal error SIGINT/SIGSTOP > > To: paawan1982@yahoo.com > > Cc: "gdb" > > Date: Thursday, February 5, 2009, 9:22 PM > > I think you didn't understand my mean. > > Why you aways want get 2 sigs? :) > > > > Hui > > > > On Thu, Feb 5, 2009 at 21:48, paawan oza > > wrote: > > > Hi, > > > please find my comment inlined. > > > Regards, > > > ..Paawan. > > > > > >> Sorry. I am not very clear your mean. > > >> > > >> What I think is before you want send a sig to a > > inferior, > > >> you can use > > >> a non-block wait or something like it to check if > > the > > >> inferior stop or > > >> not. > > > > > > Paawan: aggreed, I check with WNOHANG option with > > waitpid(...). > > > assume, it says : inferior is running (no signal from > > inferior) > > > > > > now I decide to send SIGINT > > > kill(PIDGET(inferior_ptid),SIGINT) /* stop the > > inferior */ > > > just exactly after this point, > > > gdb gets scheduled out... > > > > > > now just before, actually, kernel delivers the SIGINT > > signal to the process > > > process gets scheduled and stopped because of > > breakpoint trap. > > > and SIGINT is also delivered to the process. > > > > > > so now gdb is notified with two signals in sequence > > > if I do > > > waitpid(pid, &status, WNOHANG | WTRACED); > > > first I get SIGTRAP > > > and then SIGINT > > > > > > and having two signals finally > > > linux-nat-wait messes it up (in multithread > > applications) > > > > > > I hope I elaborated. > > > > > > Regards, > > > ..Paawan. > > > > > > > > >> If the inferior already stop by a breakpoint, this > > >> non-block wait will > > >> success. And then you don't need to send sig. > > >> > > >> If the inferior is running, this wait will false, > > it will > > >> not affect > > >> anything. You can send sig after that. > > >> > > >> > > >> Thanks, > > >> Hui > > >> > > >> On Tue, Feb 3, 2009 at 20:48, paawan oza > > >> wrote: > > >> > Hello, > > >> > > > >> > your comments. > > >> >> Why not check if this process is stop or > > not > > >> before send sig > > >> >> to them > > >> >> (use wait or something)? > > >> > > > >> > my anwser : > > >> > It falls off in one situation. > > >> > > > >> > imagine : > > >> > I send SIGINT/SIGSTOP to the process. > > >> > and then just after I send the signal to the > > process > > >> to stop. > > >> > gdb is scheeduled out. > > >> > the inferior gets shceduled in. > > >> > one of its threads already stopped because of > > >> breakpoint. > > >> > and then we have no more control. > > >> > now when gdb gets scheduled in, it ( > > linux-nat-wait) > > >> sees two signals. : ) > > >> > where it falls off. > > >> > > > >> > Regards, > > >> > ..Paawan. > > >> > > > >> > > > >> > --- On Tue, 2/3/09, teawater > > >> wrote: > > >> > > > >> >> From: teawater > > >> >> Subject: Re: gdb internal error > > SIGINT/SIGSTOP > > >> >> To: paawan1982@yahoo.com > > >> >> Cc: gdb@sourceware.org > > >> >> Date: Tuesday, February 3, 2009, 8:35 AM > > >> >> Why not check if this process is stop or > > not > > >> before send sig > > >> >> to them > > >> >> (use wait or something)? > > >> >> > > >> >> On Mon, Feb 2, 2009 at 22:47, paawan oza > > >> >> wrote: > > >> >> > > > >> >> > Hello, > > >> >> > > > >> >> > I have been modifying gdb for past > > couple of > > >> months. > > >> >> > I am trying to keep process always > > running > > >> and user > > >> >> should be able to type commands. > > >> >> > It is similar to tracepoints but on > > host > > >> system. > > >> >> > > > >> >> > I am facing a problem as following > > when try > > >> to debug > > >> >> multi-threaded applications. > > >> >> > > > >> >> > I am sending SIGINT/SIGSTOP (with no > > pass) to > > >> stop the > > >> >> process. > > >> >> > linux-nat-wait wll attempt to stop > > other > > >> threads and > > >> >> it succeeds. > > >> >> > and it works fine. > > >> >> > > > >> >> > but, > > >> >> > when I have breakpoints on > > threads.... > > >> >> > and if main/CLONEs thread is stopped > > due to > > >> breakpoint > > >> >> and if I send > > >> >> > SIGINT/SIGSTOP to the main > > thread.... > > >> >> > eventually I end up getting > > interrnal gdb > > >> assertion > > >> >> error. > > >> >> > gdb_assert (pid == GET_LWP > > (lp->ptid)); > > >> >> > > > >> >> > I would like to know !! > > >> >> > > > >> >> > 1) why is that happening ? > > >> >> > in the scenerio where (thread is > > already > > >> stopped > > >> >> because of breakpoint > > >> >> > and I am internally sending > > SIGINT/SIGSTOP > > >> (with no > > >> >> pass) > > >> >> > > > >> >> > note : I have modified gdb code to > > suite my > > >> >> requirements. where process should always > > be > > >> running and > > >> >> user should be able to type commands > > >> >> > > > >> >> > please do the needful. > > >> >> > > > >> >> > > > >> >> > Regards, > > >> >> > ..Paawan. > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> > > > >> > > > >> > > > >> > > > > > > > > > > > > > > > >