Memory-leak in THYRODLReader.MergeRODLs

Hydra
1

Hello,

I have noticed that source code in unit “Hydra.RO.RODLReader.pas” has been significantly modified compared to versions before 6.6.0.1317. Unfortunately, one of the consequences is the fact, that there is now a massive memory leak in the “MergeRODLs” method, namely - the local variables “l_mainRODL, l_subRODL” are never released and remain in memory.

See this:

procedure THYRODLReader.MergeRODLs(var MainRODL: ROUTF8String; const SubRODLs: array of ROUTF8String);

  procedure _MergeRODLs(aMainRODL, aSubRODL: TRODLLibrary);
  begin
    ......
  end;

var
// <BUG> these variables are never released
  l_mainRODL: TRODLLibrary;
  l_subRODL: TRODLLibrary;
// <BUG/> 
  i: Integer;
begin
 ....
end;

Regards, Jaroslav

2

Logged as bugs://H1034.

3

bugs://H1034 was closed as fixed.

4

Hello,

according to the information in the change log of the last official Hydra release (6.6.0.1319) this bug has been fixed, see:

https://www.remobjects.com/portal/downloads/hydra.aspx?changelog=Stable/20231115-121909-hydra-develop/hydra-1319.txt

Comparing the source code with the previous Hydra release (6.6.0.1317), I can’t find any indication that the fix has actually occurred. The content of the “Hydra.RO.RODLReader.pas” unit is identical, I don’t see any change. The only change is in the “Hydra.VCL.ControlAsVisualPlugin.pas” unit.

I am a bit confused… can you please specify how the fix was resolved in the 6.6.0.1319 release?

Regards, Jaroslav

5

Hi,

weird. your bugs (hydra and RO/DA) are fixed in preview branch
so they are fixed in .1321 and .1575 accordingly

6

According to the change log, the bug was fixed in version 6.6.0.1319, see here, again:

https://www.remobjects.com/portal/downloads/hydra.aspx?changelog=Stable/20231115-121909-hydra-develop/hydra-1319.txt

Okay, so the fix is only in version 6.6.0.1321… do I understand this correctly?

Regards, Jaroslav

7

Hi,

yes. it was fixed after .1319 was created

8

I understand… in that case the mention of the bug fix should be in the change log of version 6.6.0.1321, not .1319… this is what confused me.

Regards, Jaroslav

15

Hi,

wrong line was removed form log

1 Like
16

My sincerest apologies; there had been an overlap between when 1319 was build, this new change was committed, and the log for 1319 was generated.