Re: gdb internal error SIGINT/SIGSTOP

[teawater <teawater at gmail dot com>]

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