Re: gdb internal error SIGINT/SIGSTOP

[paawan oza <paawan1982 at yahoo dot com>]

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.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >
> >
> >
> >