Leaderboard

Next time please choose a meaningful subject for your thread.

Many of us miss call stacks in Delphi and have to use heavy or commercial libs. Luckily Microsoft cares of us and provides necessary API's. Here's the unit // Stack tracing with WinAPI // (c) Fr0sT-Brutal // License MIT unit StackTrace; interface {$IFDEF MSWINDOWS} uses Windows, SysUtils; const DBG_STACK_LENGTH = 32; type TDbgInfoStack = array[0..DBG_STACK_LENGTH - 1] of Pointer; PDbgInfoStack = ^TDbgInfoStack; function RtlCaptureStackBackTrace(FramesToSkip: ULONG; FramesToCapture: ULONG; BackTrace: Pointer; BackTraceHash: PULONG): USHORT; stdcall; external 'kernel32.dll'; procedure GetCallStackOS(var Stack: TDbgInfoStack; FramesToSkip: Integer); function CallStackToStr(const Stack: TDbgInfoStack): string; procedure InstallExceptionCallStack; {$ENDIF} implementation {$IFDEF MSWINDOWS} procedure GetCallStackOS(var Stack: TDbgInfoStack; FramesToSkip: Integer); begin ZeroMemory(@Stack, SizeOf(Stack)); RtlCaptureStackBackTrace(FramesToSkip, Length(Stack), @Stack, nil); end; function CallStackToStr(const Stack: TDbgInfoStack): string; var Ptr: Pointer; begin Result := ''; for Ptr in Stack do if Ptr <> nil then Result := Result + sLineBreak + Format('$%p', [Ptr]) else Break; end; function GetExceptionStackInfo(P: PExceptionRecord): Pointer; begin Result := AllocMem(SizeOf(TDbgInfoStack)); GetCallStackOS(PDbgInfoStack(Result)^, 1); // excluding the very function GetCallStackOS end; function GetStackInfoStringProc(Info: Pointer): string; begin Result := CallStackToStr(PDbgInfoStack(Info)^); end; procedure CleanUpStackInfoProc(Info: Pointer); begin Dispose(PDbgInfoStack(Info)); end; procedure InstallExceptionCallStack; begin Exception.GetExceptionStackInfoProc := GetExceptionStackInfo; Exception.GetStackInfoStringProc := GetStackInfoStringProc; Exception.CleanUpStackInfoProc := CleanUpStackInfoProc; end; procedure UninstallExceptionCallStack; begin Exception.GetExceptionStackInfoProc := nil; Exception.GetStackInfoStringProc := nil; Exception.CleanUpStackInfoProc := nil; end; {$ENDIF} end. test project program Project2; {$APPTYPE CONSOLE} {$R *.res} uses Windows, SysUtils, StackTrace in 'StackTrace.pas'; // Demo subs procedure Nested2; begin Abort; end; procedure Nested1; begin Nested2; end; procedure Nested0; begin Nested1; end; begin try InstallExceptionCallStack; Nested0; except on E: Exception do Writeln(E.ClassName, ': ', E.Message, sLineBreak, E.StackTrace); end; Readln; end. and output

That means you are trying to call a function through a nil function pointer. Did you check to see whether _TaskDialogIndirect is nil or not?

I don't think that's true. You should use UniqueString. But it sounds like this isn't the cause of your problem.

No. CoInitialize doesn't report errors by throwing exceptions. You are expected to check its return value. This is stated clearly in the documentation for the function which is required reading before using it. Let's leave error handling to one side for now though. The try finally pattern is like this. res := acquireResource; try res.doSomething; finally releaseResource(res); end; The try/finally is protecting the code *between* acquisition and release. Therefore the try must be *after* acquisition.

The update has problems with uninstalling some GetIt packages, e. g. Parnassus Bookmarks and Navigator. It is recommended to manually uninstall these first before you run the update. I dimly remember a blog post about this issue but cannot find it at the moment. Anyway: the GetIt uninstall opens a command window that then fails to close. Just close it yourself, you may actually be able to type "exit" at its prompt for that, otherwise shoot it down via task manager. The process will then continue normally.

Show us your definition of TCardForm. At the top of the example you declared CardForm as a TForm. The compiler is complaining that it can't find TCardForm's definition anywhere. Where is it? Maybe you're missing a unit in the uses clause?

Without seeing the code it's really hard to tell what is eating up the memory. I also have zero experience with FireDac, but... I suspect you have a query, with a DBGrid connected and this query also downloads the BLOB. The issue is that the query will at least download all the blobs for all records which are visible in the grid, worst case it downloads all. This is already using up a huge amount of memory. When you assign the value to a string, you allocate even more memory, resulting in OOM. What I'd try is to exclude the blob from the main query, add a second query with SELECT blobfield FROM MyTable WHERE ID = x. You can open this manually upon record change, load the data in the RichEdit and close it immediately. That should minimize the memory usage.

you can register your key in my.embarcadero.com and download your iso, not?

Not the answer you are looking for, but you are aware that many users these days have browser adblockers installed? I suspect depending on advertising revenue from website visits to support your application may not be the best way of funding your work on it.

INVALID_HANDLE_VALUE is not null (0), it is -1. Some APIs return 0 on failure, some return -1 instead. Be careful mixing them up. See Why are HANDLE return values so inconsistent?

Instead of all this guesswork why not simply use the debugger to determine where the out-of-memory occurs?

The famous Quick Fix™ technique - Sponsored by Intel and your local power company.

Your comment got me to remember ASLR in 11. Removing ASLR makes it work correctly. For anyone else interested, it is the 2nd to last option in Linking.

You're right for sure, that's why I recently implemented MAP file reading and extracting all the info available for any given address. Besides some tricky aspects, that wasn't too hard. I merged that with built-in stack traces and now I have fully detailed traces with module, function name and LOC. Alas, the code requires some other my routines which are not fully ready for publishing yet (translate & add comments etc). But in case someone is interested I could try to switch to built-in routines

Then don't use ShowMessage() for that. It displays a modal TForm whose owner window (in Win32 API terms, not VCL terms) is the currently active TForm. An owned window is always on top of its owning window. For what you describe, use a normal TForm instead of ShowMessage(). Set its PopupParent property to the monitoring TForm that needs attention, and then show the popup TForm. This way, the popup Tform stays on top of only its monitoring TForm, but other TForms can appear on top of the popup TForm. Otherwise, change your UI to not use a popup TForm at all. Put a visible message inside the TForm that needs attention.

Let's enumerate... Embarcadero servers decongested = OK Mega-fast user internet (ultra-broadband) = OK User's computer latest generation and mega-fast = OK No software to disturb the download = OK user using a VM with many gigabytes of RAM and disk (+100GB) = oh oh oh will it? ... let's wait and see.... until the end, cross your fingers and hope that no problems with the connection to Embarcadero, or even, no internal errors during the installation!!! NOTE: download ISO (+6gb) in order not to get bored!

P.S. Good luck with the writing