Heaptrc issue

[peardox]

I've got a form with a button on it

The button, if pressed, loads 160M+ of data into an external DLL then destroys it (testing this all works)

Now. with heaptrc enabled, I run my app, don't press the button and get heap1.png (attached) when I close the application

So far so good

Repeat the test but press the button and kill the app results in heap2.png (attached)

Why do the reports differ? The heap sizes are still the same.

If I press the button and close the a[[ then leave the heaptrc on the screen > a min or so I get a SIGSEGV (DLL unload or something?)

If button not pressed then no SIGSEGV

If heaptrc OK pressed use the app exits without the SIGSEGV

[jamie]

Assuming you are using the memory manager in the app and passing the pointer to the DLL, the report looks normal.

 When you press the button you allocated 160+ megs of memory where as when you didn't press the button no memory was allocated most likely because you didn't process that 160M file or where ever it came from.

 As for the SegFault, I've seen it do that in Windows 10 if something else is going on with your desktop while the HeapTrc screen is just sitting there. I think it has something to do with changing focus on the screen.

[peardox]

Yeah - button = Read 160+M and throw it at DLL then destroy DLL copy + release everything

No button = do sod all

So, the debugger has control after the program has exited? This making the DLL a canidate for reclaiming space and thus causing a SIGSEGV? The application has actually terminated at this point?

I was getting a load of seg faults before I re-wrote the pascal end of things - just paranoid I've missed something (looks like not though hopefully)

[Martin_fr]

I dont think, that the sigsegv during the heaptrc win has anything to do with your code.

Heaptrc runs when all else is done. Your app has finished, and returned all the mem it ever used (or if not, in case of a leak, your app has exited any code that could do so...
The only code still running is from the system unit and the mem-manager.

When that window pops up, heaptrc has finished its report on your mem.
That window is somewhere in the LCL (its an addition to heaptrc), and uses the most basic access to the windows API. (and maybe those calls are buggy)


If you build your app with console -WC, then the leaks will be printed there.
There is also an environment app that allows the report to go to a file.

--------
If you are concerned about your app causing errors:
-Compiles with all the whistles enabled.  A few are  -CRiot -gt
  the -gt  can be varied with 1 to 4 t. -gt -gtt -gttt -gtttt
  Each of them does a diff test, so test your app with all 4 of them.

Heaptrc also has a "keepreleased" option (via environment / google / search forum/wiki). This can help finding mem access violations.

If you need the ultimate check, you will need to test on Linux. There is a tool called valgrind, and it can check for a lot of issues.

[jamie]

From my observations I've seen this happen if I leave it unattended with the screen up and with my system I am getting the standard notifications alerts MS and who ever likes to put in the tray at the right, I Think it's then when one of these notices popup is when this happens while the HeapTrc report screen is sitting idle.