Access Violation in SetAckDetails() if SkipAck = True

There are two problems actually:

  1. Access Violation in SetAckDetails(). If SkipAck = True, the Event object will not assigned, and this method will raise AV in some High Load scenarios.

  2. Possible race condition, there is no need to unlock the list when removing. Between unlocking and locking again the list can be changed.

In our project we use SkipAck = True, and face AV from time to time (pretty random) with such call stack:

image

Logged as bugs://D19499.

bugs://D19499 was closed as fixed.

Hi,

it you want to fix 1. manually, look for .Event. in

  • uROBaseSuperTcpConnection.pas
  • uROBaseSuperTCPChannel.pas
  • uROBaseSuperChannel.pas
  • uROBaseSuperHttpChannel.pas

and update code like:

if Assigned(rp.Event) then 
  rp.Event.SetEvent;

Thank you EvgenyK. We already made such a fix, and it seems to work after 3 days of testing.

Regarding your suggestions, from my point of view, only the uROBaseSuperTcpConnection.pas needs to be fixed (SetAckDetails). In all other places RO access TROWaitingRequest.Event that is always initialized and doesn’t depend on SkipAck.

1 Like