linuxyne wrote:
MollenOS wrote:
Ahh I see - but as you said the structure members will always be present even if not compiled as 64 bit.
Yes, you are correct. The presence of the extended members in the structures is not controlled by the __BITS config. Thus, an out-of-bounds read is unlikely due to this particular reason.
MollenOS wrote:
I tried extending the delay from 1 second to 3 seconds and run a few times until the crash came after, nothing changes it's stuck on the first qtd with the Active + XActErr bit set. It seems it crashes while processing the first transaction. What could this indicate? I mean it would be obvious that the buffer pointers are wrong, but I've double checked them, and they are valid.
The setup buffer can be rejected as the source of the problem by setting the length (in the setup packet) as 0 instead of 8. Assuming that vbox avoids accessing the buffer address if the length field is 0, we can expect to receive a clean, straightforward error.
Edit: Sorry, above I meant "The setup buffer can be confirmed ..." and not "The setup buffer can be rejected..."
OK, so this became very interesting - I did as you said and changed the length to 0 on the setup td. It now does NOT crash and instead gives me a clean error (XActError)
This could indeed indicate my buffer being invalid and reveals I have a hidden problem somewhere, I setup the SetAddress packet here:
Code:
Packet = (UsbPacket_t*)PacketBuffer;
Packet->Direction = USBPACKET_DIRECTION_OUT;
Packet->Type = USBPACKET_TYPE_SET_ADDRESS;
Packet->ValueLo = (uint8_t)(Address & 0xFF);
Packet->ValueHi = 0;
Packet->Index = 0;
Packet->Length = 0;
So it obviously crashes on either the buffer address being invalid or the packet containg bogus data? What other reasons for this?