Re: gdb internal error SIGINT/SIGSTOP

[paawan oza <paawan1982 at yahoo dot com>]

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