Thanks @mark1,
I was able to attach a debugger and found that our USB analyzer is getting into an infinite loop while it’s trying to parse a control request. I’m still digging through the session, and I haven’t been able to identify the problem yet.
I believe it is in the middle of parsing the response to a string descriptor read. Descriptor index 3.
The value the analyzer has decoded for the string descriptor at this point is “123-32”.
The problem is that the analyzer believes that there is still more data to be parsed from this, however it has nothing left to parse. As if there are 5 more bytes that need to be processed before it will exit this processing loop.
This is the while loop at the top of void USBControlTransferParser::ParseDataPacket( USBPacket& packet ) in USBControlTransfers.cpp, specifically while( mPacketDataBytes > mPacketOffset ).
@KurtE, thanks for running this with your version. Could you send me a link? Also, is yours running in at the control transfer layer? I suspect that lower levels of decoding might skip this issue, but I need to check.
The analyzer does work properly when set to the “Packets” decode level. However it may be tricky to change to this mode, because the analyzer will start running with the last used settings the moment you add it. If this is a problem, simply take a new capture with no data, add the USB analyzer, change the settings, and close it. This will change the default settings for the next time you add the USB analyzer to your saved capture. I’ve attached a new copy of the save file with the analyzer already reset as needed.
I believe this is the point in the data where the descriptor is being read, and I can see the descriptor contents in hex “123-321”. Note that the analyzer had failed to parse the last character “1”.
What’s particularly odd is that if I trim the capture to be a little longer than this point, I can see that the analysis always ends there, but the software no longer locks up completely. I’ll need to debug this more closely. I suspect that whatever goes wrong here puts the USB analyzer into a bad state, but that bad state does not ultimately cause the infinite loop until later through the capture.
LoopingCapture2_packets.sal (5.8 MB)
