gdb internal error SIGINT/SIGSTOP

gdb internal error SIGINT/SIGSTOP

[paawan oza]

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.





















      

Re: gdb internal error SIGINT/SIGSTOP

[Daniel Jacobowitz]

On Mon, Feb 02, 2009 at 06:47:02AM -0800, 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.

Please look at the non-stop debuging which is supported in HEAD.
You will have to change a lot of the same things that non-stop did.

> 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));

Sorry, there is no way for us to know the answer to this question
since you have made extensive changes to your GDB.


-- 
Daniel Jacobowitz
CodeSourcery

Re: gdb internal error SIGINT/SIGSTOP

[paawan oza]

Hello,

I completely understand, and I appreciate what you have said.
but is it possible to answer following ?

1) in what all situation
gdb_assert (pid == GET_LWP (lp->ptid)) could come
(I am using gdb-6.7)
I do not expect too much technical internal details of gdb here...
but at an abstract level, if it is possible to explain.

2) I would like to contribute in open source for reversible debugging.
but I am not getting any clue how I can start and where to go ahead ?
would you please guide me ?

Regards,
..Paawan.



--- On Mon, 2/2/09, Daniel Jacobowitz <drow@false.org> wrote:

> From: Daniel Jacobowitz <drow@false.org>
> Subject: Re: gdb internal error SIGINT/SIGSTOP
> To: "paawan oza" <paawan1982@yahoo.com>
> Cc: gdb@sourceware.org
> Date: Monday, February 2, 2009, 8:35 PM
> On Mon, Feb 02, 2009 at 06:47:02AM -0800, 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.
> 
> Please look at the non-stop debuging which is supported in
> HEAD.
> You will have to change a lot of the same things that
> non-stop did.
> 
> > 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));
> 
> Sorry, there is no way for us to know the answer to this
> question
> since you have made extensive changes to your GDB.
> 
> 
> -- 
> Daniel Jacobowitz
> CodeSourcery


      

Re: gdb internal error SIGINT/SIGSTOP

[Daniel Jacobowitz]

On Mon, Feb 02, 2009 at 07:20:26AM -0800, paawan oza wrote:
> Hello,
> 
> I completely understand, and I appreciate what you have said.
> but is it possible to answer following ?
> 
> 1) in what all situation
> gdb_assert (pid == GET_LWP (lp->ptid)) could come
> (I am using gdb-6.7)
> I do not expect too much technical internal details of gdb here...
> but at an abstract level, if it is possible to explain.

I have no idea, sorry.

> 2) I would like to contribute in open source for reversible debugging.
> but I am not getting any clue how I can start and where to go ahead ?
> would you please guide me ?

Take a look at gdb/CONTRIBUTE, and ask specific questions of the
people working on it (especially teawater and Michael Snyder).


-- 
Daniel Jacobowitz
CodeSourcery

Re: gdb internal error SIGINT/SIGSTOP

[teawater]

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

Re: gdb internal error SIGINT/SIGSTOP

[teawater]

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.

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

Re: gdb internal error SIGINT/SIGSTOP

[paawan oza]

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


      

Re: gdb internal error SIGINT/SIGSTOP

[teawater]

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

Re: gdb internal error SIGINT/SIGSTOP

[paawan oza]

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


      

Re: gdb internal error SIGINT/SIGSTOP

[teawater]

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

Re: gdb internal error SIGINT/SIGSTOP

[paawan oza]

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