From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26067 invoked by alias); 6 Feb 2009 07:54:32 -0000 Received: (qmail 26057 invoked by uid 22791); 6 Feb 2009 07:54:30 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,J_CHICKENPOX_73 X-Spam-Check-By: sourceware.org Received: from web36208.mail.mud.yahoo.com (HELO web36208.mail.mud.yahoo.com) (209.191.68.234) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Fri, 06 Feb 2009 07:54:21 +0000 Received: (qmail 82802 invoked by uid 60001); 6 Feb 2009 07:54:19 -0000 Received: from [123.237.142.21] by web36208.mail.mud.yahoo.com via HTTP; Thu, 05 Feb 2009 23:54:19 PST Date: Fri, 06 Feb 2009 07:54: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: <650218.82166.qm@web36208.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/msg00059.txt.bz2 Hi Hui, Exactly, you have made the point. > 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. in inferior fly mode the behavior is as follows : -> if inferior is stopped at breakpoint/watchpoint, gdb collects debug info (registered by 'commands') and logs into the file (using bpstat_do_actions -> now all these time user can still input the commands. now here is the catch. if user gives a command (e.g. set breakpoint), which modifies inferior's address space, so there is a need to stop the inferior. but as I mentioned, when I send SIGINT to stop the inferior..... inferior already stopped because of some brekpoint. so in multi-thread programs, in fly mode, where multiple breakpoitns in diffirent threads keep on hitting breakpoints... eventually linux-nat-wait -> stop_wait_call_back -> wait_lep function throws an assertion gdb_assert (pid == GET_LWP (lp->ptid)); PS : it works perfectly fine with single threaded programs. but multithread program it doesnt work. Regards, ..Paawan. --- On Fri, 2/6/09, teawater wrote: > From: teawater > Subject: Re: gdb internal error SIGINT/SIGSTOP > To: paawan1982@yahoo.com > Cc: "gdb" > Date: Friday, February 6, 2009, 10:46 AM > 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. > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > > > > > > > > > > > > > > > > > > > >