This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: About "process 42000"

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.

On Fri, Apr 3, 2009 at 11:15 AM, Pedro Alves <> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]