Re: Remote mutli-threaded debugging with large number of threads

[Maciej Sikorski <m dot sikorski0 at poczta dot onet dot pl>]

Comparison of correct situation logs from connection to one with incorrect behaviour (the same application that starts working after different one opens connection first) shows something like this:
Correct case:
Packet received: 000000b0308281803082ff8000000004308282500000000000000008000000000002d0000000000030828b780000000048044422105724bc39c0629839c0627839c062580ff05c5c300287580ffef8c00fe968040f94c2380ff05c900ff05c7c0ff05c780ff05c740ff05c680ff05c6400000002308282500ff0c71c30828250000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f0fa5180002d000580444420f0fa62c000000000000000000000000
Sending packet: $mf0fa518,4#c8...Ack
Packet received: 7c000026

Incorrect case:
Packet received: 000000b0308281803082ff8000000004308282500000000000000008000000000002d0000000000030828b780000000048044422105724bc39c0629839c0627839c062580ff05c5c300287580ffef8c00fe968040f94c2380ff05c900ff05c7c0ff05c780ff05c740ff05c680ff05c6400000002308282500ff0c71c30828250000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f0fa5180002d000580444420f0fa62c000000000000000000000000
Sending packet: $m0,4#fd...Ack
Packet received: E01
E01
    The stub-side thread library does not have the required thread local
    storage support.

I assume hex after $m is address that gdb is asking about

How is this possible that in bad case address is 0?
 
Logs before these sequences do not show any differences. It looks like that GDB in both cases received f0fa518, but in second case it sends $m0 instead of $mf0fa518. 
It also looks strange to me that after "opening pipe" (first attach to different application that always works) problem is gone.

Can you help with further diagnosis and potential root cause finding?

Maciej Sikorski



m.sikorski0@poczta.onet.pl napisa³:
>Yes, I agree it has nothing to do with application size - just confirmed that I can see correctly threads of 17 meg binary. 
>Interesting thing is that after running debug session on first working application (one that problem never appeared), then detaching and attaching to second one everything works perfectly.
>
>Gdbserver is restarted and attached to a second app. It seems that it is a matter of configuration GDB keeps from previous connection.
>This is a kind of workaround for me, but still dont know root cause. Any suggestions what I can look for in remote debug logs?
>
>Maciej Sikorski
>