Re: gdb internal error SIGINT/SIGSTOP

[teawater <teawater@gmail.com>]

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