Leaderboard

I tried to install and use OpenCV under C++Builder 10.3.3 (see stack overflow), until now without success. Wouldn't it possible that Embarcadero could make this important library available via GetIt or at least provide a short installation tutorial with working dll's and import libs ? For Delphi there is a project on GitHub (Delphi-OpenCV) but it's an old version and I don't know if it can be used in C++Builder. At the moment there are 15 C++ libraries available on GetIt. Not very much compared to MS VC (ca. 800) . I don't need 800 but it is rather frustrating if I see an interesting library but install/compiling instructions only for GCC or MS VC or just precompiled packages only for MS VC.. Some libraries are easier to install than OpenCV, e.g. NLopt for non-linear optimization that I tested. Would also be a candidate for GetIt. Maybe I belong to a minority of RAD Studio users because I need many mathematical and scientific libraries and these libraries have low priority for Embarcadero. Then let me know...

OK, the expressions can become quite hard to manage, so I can see why people are not really that enthusiastic about regex, but here is now my complete list: SetLength\s*\(.*Length\(.*\)\s*\+\s*1 -> SetLength(arr, Length(arr) + 1) SetLength\s*\(.*High\s*\(.*\)\s*\+\s*1 -> SetLength(arr, High(arr) + 1) 0\s*to\s*.*Count\s*do -> 0 to List.Count do 0\s*to\s*.*Length\s*\(.*\)\s*do -> 0 to Length(arr) do raise Exception\( -> raise Exception() (missing .Create like in raise Exception.Create) Exception\.Create\( -> Exception.Create( (verify that Raise is in front ) Full exp: (SetLength\s*\(.*Length\(.*\)\s*\+\s*1)|(SetLength\s*\(.*High\s*\(.*\)\s*\+\s*1)|(0\s*to\s*.*Count\s*do)|(0\s*to\s*.*Length\s*\(.*\)\s*do)|(raise Exception\()|(Exception\.Create\() And of course Delphi's IDE is special and requires a little subtle changes: Delphi IDE: SetLength\s*\(.*Length\(.*\)\s*.*\+\s*.*1 SetLength\s*\(.*High\s*\(.*\)\s*.*\+\s*.*1 0\s*.*to\s*.*.*Count\s*.*do 0\s*.*to\s*.*Length\s*\(.*\)\s*.*do Full exp: (SetLength\s*\(.*Length\(.*\)\s*.*\+\s*.*1)|(SetLength\s*\(.*High\s*\(.*\)\s*.*\+\s*.*1)|(0\s*.*to\s*.*.*Count\s*.*do)|(0\s*.*to\s*.*Length\s*\(.*\)\s*.*do)|(raise Exception\()|(Exception\.Create\()

@Remy Lebeau The LStrFromPWCharLen entry indeed looks wrong - but the lines before and after that exactly match with the 10.3.3 code - I just checked. Maybe it's just a glitch in the stack walking code done by FastMM_FullDebugMode.dll Edit: Yep - I can repro the wrong entry in the call stack with this code: uses FastMM5, System.SysUtils; var x: TBytes; s: string; r: RawByteString; begin s := 'test'; r := RawByteString(s); SetLength(x, 10); Pointer(x) := nil; ReportMemoryLeaksOnShutdown := True; end. and get this report: This block was allocated by thread 0x432C, and the stack trace (return addresses) at the time was: 004128BA [FastMM5.pas][FastMM5][FastMM_DebugGetMem$qqri][7717] 0040476D [System.pas][System][@ReallocMem$qqrrpvi][5022] 00408181 [System.pas][System][DynArraySetLength$qqrrpvpvipi][36046] 00406E08 [System.pas][System][@LStrFromPWCharLen$qqrr27System.%AnsiStringT$us$i0$%pbius][26213] <-- ?!?! 004082C2 [System.pas][System][@DynArraySetLength$qqrv][36150] 004265D9 7732FA29 [BaseThreadInitThunk] 77E87C7E [RtlGetAppContainerNamedObjectPath] 77E87C4E [RtlGetAppContainerNamedObjectPath] My guess would be that the: PUSH ESP ADD dword ptr [ESP],4 in _DynArraySetLength is not properly handled by the stack walking code. Obviously, a defect in JclDebug LogStackTrace in FastMM_FullDebugMode.dpr - compiling FastMM_FullDebugMode.dll with madExcept gives this call stack as it just passes to madStackTrace.FastMM_LogStackTrace which seems to do a better job: 004128b5 +015 Project53.exe FastMM5 7717 +4 FastMM_DebugGetMem 00404767 +03f Project53.exe System 5022 +91 @ReallocMem 0040817c +16c Project53.exe System 36046 +70 DynArraySetLength 004082bd +005 Project53.exe System 36150 +3 @DynArraySetLength 7732fa27 +017 KERNEL32.DLL BaseThreadInitThunk Probably the bug is in GetRawStackTrace and madExcept is just able to fix it - I am not entirely sure - as far as I can see there is no method in JclDebug that can build a call stack from the data that FastMM_FullDebugMode GetRawStackTrace collects - that is why LogStackTrace simply iterates the entries and calls GetLocationInfo on each of them and just concats them. @Pierre le Riche fyi

Important: a memleak report just tells where the memory was allocated that got leaked not the code that actually caused the leak. You need to review the code in NodeGetBase64Value and check what it does with the result of Mime64Decode and where it passes that.

This is the key line. Now let's think, where this strange "-32000" numbers may araise at all. I'm sure 99.9% that the numbers are received from a Windows API function call, such as GetWindowRect (or similar) in minimized window state (IsIconic(Handle) = True). Simple experiment proves it: procedure TForm1.Timer1Timer(Sender: TObject); var wr: TRect; begin if WindowState = TWindowState.wsMinimized then begin GetWindowRect(Handle, wr); OutputDebugString(PChar(wr.Left.ToString + ', ' + wr.Top.ToString)); end; end; So: With "-32000" left and top values the window is not, of course, within the area of your monitor 1, but this monitor becomes the closest one to the window.