Re: gdb internal error SIGINT/SIGSTOP

[paawan oza <paawan1982 at yahoo dot com>]

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 <teawater@gmail.com> wrote:

> From: teawater <teawater@gmail.com>
> Subject: Re: gdb internal error SIGINT/SIGSTOP
> To: paawan1982@yahoo.com
> Cc: "gdb" <gdb@sourceware.org>
> 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
> <paawan1982@yahoo.com> 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
> <teawater@gmail.com> wrote:
> >
> > > From: teawater <teawater@gmail.com>
> > > Subject: Re: gdb internal error SIGINT/SIGSTOP
> > > To: paawan1982@yahoo.com
> > > Cc: "gdb" <gdb@sourceware.org>
> > > 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
> > > <paawan1982@yahoo.com> 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
> > > >> <paawan1982@yahoo.com> 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
> > > >> <teawater@gmail.com> wrote:
> > > >> >
> > > >> >> From: teawater
> <teawater@gmail.com>
> > > >> >> 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
> > > >> >> <paawan1982@yahoo.com>
> 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.
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >
> > > >
> > > >
> > > >
> >
> >
> >