From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31917 invoked by alias); 5 Feb 2009 16:22:22 -0000 Received: (qmail 31905 invoked by uid 22791); 5 Feb 2009 16:22:21 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_73 X-Spam-Check-By: sourceware.org Received: from web36204.mail.mud.yahoo.com (HELO web36204.mail.mud.yahoo.com) (209.191.68.230) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Thu, 05 Feb 2009 16:22:15 +0000 Received: (qmail 86593 invoked by uid 60001); 5 Feb 2009 16:22:13 -0000 Received: from [123.238.99.209] by web36204.mail.mud.yahoo.com via HTTP; Thu, 05 Feb 2009 08:22:13 PST Date: Thu, 05 Feb 2009 16:22:00 -0000 From: paawan oza Reply-To: paawan1982@yahoo.com Subject: Re: gdb internal error SIGINT/SIGSTOP To: teawater Cc: gdb In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <329369.85710.qm@web36204.mail.mud.yahoo.com> 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/msg00044.txt.bz2 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. > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> > > >> > > >> > > >> > > > > > > > > >