EldoS | Feel safer!

Software components for data protection, secure storage and transfer

MsgConnect v.

Posted: 01/30/2007 21:44:20
by Christopher Zielinski (Basic support level)
Joined: 04/16/2006
Posts: 28

"MsgConnect - version - released November 18, 2006" stated in its change history (what's new text file document), that it had turned off compiler optimizations as they seemed to be causing problems for its Pascal, ActiveX, and DLL builds.

Based on this information, I disabled/turned-off the Delphi compiler's code generation optimization under my software project's compiler options.

This is the first time that I have ever disabled this option in my seven years of Delphi software application development.

I found that changing this setting caused a FOR-NEXT loop coding style that I have used for decades to fail and would also consider this failure to be a compiler code generation error. More specifically, when iterating through a dynamic collections, I often use this programming style (which works 100% of the time when Compiler > Code Generation > Optimization is enabled/turn-on):

function TLanCteCalls.FindCall(vDevId: tDeviceId; vCallId: tCallId): TLanCteCall;
  iCnt, iEnd: Integer;
  iEnd := (Count - 1);
  for iCnt := 0 to iEnd do begin
    with Items[iCnt].CallInfo^.event.cpCallInfo do begin
      if ((deviceId = vDevId) and (callId = vCallId)) then
  if (iCnt > iEnd) then
    Result := nil
    Result := Items[iCnt];

Notice the (iCnt > iEnd) comparison that is done after the FOR-NEXT loop? Well both the iCnt and iEnd variables remain in scope, but I have found that:

  • The FOR-NEXT control variable is guaranteed to be assigned its initialization value if the Compiler > Code Generation > Optimization is enabled/turn-on
  • The FOR-NEXT control variable can have any arbitary value if Compiler > Code Generation > Optimization is disabled/turn-off and no statements within the FOR-NEXT loop is are executed.
  • In other words, turning off the Compiler > Code Generation > Optimization produces code that evaluates a FOR-NEXT assignment value prior to assigning it to the counter FOR-NEXT loop variable.

Proof that this is a compiler error is simple enough, as the compiler produces a "Hint" that says the correcting code is never used ("[Hint] untLanCte.pas(935): Value assigned to 'iCnt' never used"). The correcting code being the assignment of a value to the FOR-NEXT control variable immediately prior to the execution of the FOR-NEXT loop.

Due incorrect code being generated by the Delphi compiler, a memory access violation could occur whenever the collection is empty and the FOR-NEXT loop counter variable contained a negative value. The memory access violation led to an exception being thrown (possibly corrupting the Delphi Remote Debugger in the process), and code flow jumping directly to an exception handler. In other words, it could appear that MsgConnect is responsible for a Delphi compiler flaw, if all that is changed in a project is its compiler optimization settings and the verion of MsgConnect used.

Testing has also verified that the following issues have been addressed in MsgConnect and that it is capable of providing very reliable communications now.

November 18, 2006
v. Maintenance update.
- (Pascal, ActiveX, DLL) Turned off compiler optimization as it seems to be causing problems
November 4, 2006
v. Maintenance update.
- (.NET, Pascal, ActiveX, DLL) Improved handling of connection error (when the host is not accessible)
October 25, 2006
v. Maintenance update.
- (Pascal, ActiveX, DLL) UDP sockets were not closed when the UDPTransport was turned off. Fixed.
June 20, 2006
v. Maintenance update.
!!! Upgrade is strongly recommended for all code bases.
- Fixed some synchronization problems in MCInetTransport, which appeared under heavy multithreaded use.
- Fixed a synchronization problem which appeared when Messenger.DispatchMessages for one Messenger was called from multiple threads at the same time.
January 9, 2006
v. Minor update.
!!! Upgrade is strongly recommended for Pascal, ActiveX, DLL code bases.
- (Pascal, ActiveX, DLL) Fixed socket resource leak in server-side socket transport.
December 19, 2005
v. Minor update
- Fixed possible infinite loop which happened when cleaning the queue from messages to disconnected clients.



Topic viewed 7062 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!