About "process 42000"

About "process 42000"

[Shrinand Javadekar]

Hi,

I see "process 42000" in the output of an "info threads" command.

What exactly is this process with id 42000? And what is its significance?

Thanks in advance.
-Shri

Re: About "process 42000"

[Hui Zhu]

remote and remote-sim (maybe some others) use this 42000 to be the
dummy pid number because they don't have really inferior in host.

Thanks,
Hui


On Fri, Apr 3, 2009 at 09:10, Shrinand Javadekar <shrinand@gmail.com> wrote:
> Hi,
>
> I see "process 42000" in the output of an "info threads" command.
>
> What exactly is this process with id 42000? And what is its significance?
>
> Thanks in advance.
> -Shri
>

Re: About "process 42000"

[Michael Snyder]

Shrinand Javadekar wrote:
> Hi,
> 
> I see "process 42000" in the output of an "info threads" command.
> 
> What exactly is this process with id 42000? And what is its significance?

In the past, 42000 was a magic thread id that was supplied by remote.c
in the case where we did not have any actual thread ids.

Now, however, I am seeing it even in cases where we do have
a list of real thread ids from the remote target.

Seems like a bug to me...

Re: About "process 42000"

[Pedro Alves]

On Friday 03 April 2009 18:58:50, Michael Snyder wrote:
> Shrinand Javadekar wrote:
> > Hi,
> > 
> > I see "process 42000" in the output of an "info threads" command.
> > 
> > What exactly is this process with id 42000? And what is its significance?
> 
> In the past, 42000 was a magic thread id that was supplied by remote.c
> in the case where we did not have any actual thread ids.
> 
> Now, however, I am seeing it even in cases where we do have
> a list of real thread ids from the remote target.
> 
> Seems like a bug to me...

Can you be a bit more specific?  A gdb log showing what you're talking
about would be helpful.  A debug remote log would probably also help.
Since there are a bunch of optional packets, I may have
missed some combination.

-- 
Pedro Alves

Re: About "process 42000"

[Shrinand Javadekar]

Ooops... I think this was because of my mistake. I have my own gdb
server. In the list of processes being returned for "info threads", I
was returning a process with pid 0. Gdb would then give this a process
id of 42000.

Sending packet: $qsThreadInfo#c8...Ack
Packet received: m0
[New process 42000]

Gdb then shows "process 42000" in the output. However, from here on,
it does not try to find out if this process is alive. It will always
show "process 42000" in the output. So every "info threads" command
after this one will have "process 42000" in the output.

Thank you everyone.
-Shri

On Fri, Apr 3, 2009 at 11:15 AM, Pedro Alves <pedro@codesourcery.com> wrote:
> On Friday 03 April 2009 18:58:50, Michael Snyder wrote:
>> Shrinand Javadekar wrote:
>> > Hi,
>> >
>> > I see "process 42000" in the output of an "info threads" command.
>> >
>> > What exactly is this process with id 42000? And what is its significance?
>>
>> In the past, 42000 was a magic thread id that was supplied by remote.c
>> in the case where we did not have any actual thread ids.
>>
>> Now, however, I am seeing it even in cases where we do have
>> a list of real thread ids from the remote target.
>>
>> Seems like a bug to me...
>
> Can you be a bit more specific?  A gdb log showing what you're talking
> about would be helpful.  A debug remote log would probably also help.
> Since there are a bunch of optional packets, I may have
> missed some combination.
>
> --
> Pedro Alves
>



-- 
Discover the 'web' of videos
www.videonym.com

Re: About "process 42000"

[Michael Snyder]

Shrinand Javadekar wrote:
> Ooops... I think this was because of my mistake. I have my own gdb
> server. In the list of processes being returned for "info threads", I
> was returning a process with pid 0. Gdb would then give this a process
> id of 42000.
> 
> Sending packet: $qsThreadInfo#c8...Ack
> Packet received: m0
> [New process 42000]
> 
> Gdb then shows "process 42000" in the output. However, from here on,
> it does not try to find out if this process is alive. It will always
> show "process 42000" in the output. So every "info threads" command
> after this one will have "process 42000" in the output.
> 
> Thank you everyone.
> -Shri


Yep, seems like a false alarm, Pedro.

Sorry!   ;-)

Re: About "process 42000"

[Pedro Alves]

On Friday 03 April 2009 22:46:25, Shrinand Javadekar wrote:
> Ooops... I think this was because of my mistake. I have my own gdb
> server. In the list of processes being returned for "info threads", I
> was returning a process with pid 0. Gdb would then give this a process
> id of 42000.

Ah, I see.  both -1 and 0 have special meaning in the remote protocol.
Thread '0' will more or less work since selecting thread 0 (Hg0 or Hc0)
0 means "select any thread", and 0 would be an "any thread".  You're
better off avoiding doing that.

> Sending packet: $qsThreadInfo#c8...Ack
> Packet received: m0
> [New process 42000]
> 
> Gdb then shows "process 42000" in the output. However, from here on,
> it does not try to find out if this process is alive. It will always
> show "process 42000" in the output. So every "info threads" command
> after this one will have "process 42000" in the output.

This is GDB assuming that the main thread is always
alive (src/gdb/remote.c:remote_thread_alive), for targets that
don't support qC or reporting the thread id in the T stop
reply packet, after a vAttach...  You will indeed stop seeing
this happen when you make your target not report a thread id
of 0.

-- 
Pedro Alves