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

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:
000000b0308281803082ff80000000043082825000000000000000080000
00000002d0000000000030828b780000000048044422105724bc39c06298
39c0627839c062580ff05c5c300287580ffef8c00fe968040f94c2380ff0
5c900ff05c7c0ff05c780ff05c740ff05c680ff05c640000000230828250
0ff0c71c3082825000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000f0fa5180002
d000580444420f0fa62c000000000000000000000000
Sending packet: $mf0fa518,4#c8...Ack
Packet received: 7c000026

Incorrect case:
Packet received:
000000b0308281803082ff80000000043082825000000000000000080000
00000002d0000000000030828b780000000048044422105724bc39c06298
39c0627839c062580ff05c5c300287580ffef8c00fe968040f94c2380ff0
5c900ff05c7c0ff05c780ff05c740ff05c680ff05c640000000230828250
0ff0c71c3082825000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000f0fa5180002
d000580444420f0fa62c000000000000000000000000
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.sikorski0poczta.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
>