[Closed]Indy10 hangs the app if using HeapTrac

[LeP]

@LeP

This:
https://github.com/IndySockets/Indy/issues/461#top

Where Remy explains it...

Thanks @Thaddy, I will make some test about that, but seems that those leaks don't do any damages to application. I have an app that is running since two years without any interruption and it has no issues on memory ... I mean that no abnormal memory usage was detected during use, until now 

[Remy Lebeau]

This is harmless, except for heaptrc.

I've neave heard of HeapTrc hanging an app if a leak occurs. The only way I can think of that happening is if it's displaying a popup message that is being hidden from the user so they can't dismiss it.

( I believe I once used AddExitProc + a small procedure to fix that, but I am no longer using any Indy code whatsoever)

However, AddExitProc is application-level, not library-level. If Indy were to use AddExitProc, it could cause problems if Indy were compiled as an external package and then loaded/unloaded dynamically at runtime.

In Delphi, using ReportLeak.... function or FASTMM5 with debugger dll doesn't report or show anything. I tryed this sometimes ago, but I don't have any visible leaks on my software.

As stated earlier, in Delphi the "intentional" leaks in Indy are registered with the memory manager so they don't appear in leak reports. The default memory manager in FPC doesn't have that feature.

There are 2 TIDThread.Create which creates a critical section

and there is only 1 TIDThread.Destroy which free's a critical section

Improper cleanup code.

That's not what is happening. Especially since you say the problem occurs even without any Indy components being active.

Indy simply creates 2 global objects at initialization, and does not free them by default at finalization. That's the leak. Has nothing to do with threads being created and not cleaned up.

Ok, got all the leaks out.

there is also a commented section in the FINAIIZE section of the "IDSTACK", I uncommented that and rebuilt it all.

So these are the files:

IDTHREAD.PAS
IDSTACK.PAS

uncomment the sections in the finalize, and rebuild the IDE.

I am sure there are many more sitting in the soup can.

The correct way to "fix" the leaks is to edit Indy's IdCompilerDefines.inc to define FREE_ON_FINAL (see lines 38-41):

Code: [Select]

// $DEFINE the following if the global objects in the IdStack and IdThread
// units should be freed on finalization
{.$DEFINE FREE_ON_FINAL}
{$UNDEF FREE_ON_FINAL}
Change to:

Code: [Select]

// $DEFINE the following if the global objects in the IdStack and IdThread
// units should be freed on finalization
{$DEFINE FREE_ON_FINAL}
{.$UNDEF FREE_ON_FINAL}
And then recompile Indy. No need to edit Indy's source code otherwise.

[Thaddy]

@Remy Lebeau
You are probably right about the hidden Window.
But heaptrc has settings to only report on leaks at program exit.
https://wiki.freepascal.org/heaptrc#Continue_execution_even_on_heap_error

[LeP]

@Remy Lebeau
You are probably right about the hidden Window.
But heaptrc has settings to only report on leaks at program exit.
https://wiki.freepascal.org/heaptrc#Continue_execution_even_on_heap_error

@Thaddy, you are right, but Remy talks about SELECTIVE leaks "registration" (like in Delphi), not all leaks of the application.

Using the settings you indicate your action is about all leaks, not a specific leaks only.

[jamie]

Sounds like we are sweeping it under the rug in favor of covering user mistake codes.

I dont code that way.

Sorry.
Jamie

[Thaddy]

Leaving intentional leaks until program close down is not necessary programmer mistake, Jamie.
And Remy shows how to solve it. But that solution may cause the problems why he did allow those leaks all over again.

That was not a fair answer, or you still don't understand it.

If it was about my solution: last gasp but that works! or you still don't understand it.

I would do what Remy showed and keep a lot of asserts in.

[jamie]

I dont agree and ill leave it at that.

Its like creating an allocated pointer resource and then later simply set it to nil and call it good coding.

 I've seen that from what i would consider a real coder, until i see practices like that.

Have a good time, i am out of this one.

Jamie

[marcov]

I dont agree and ill leave it at that.

Its like creating an allocated pointer resource and then later simply set it to nil and call it good coding.

 I've seen that from what i would consider a real coder, until i see practices like that.

Have a good time, i am out of this one.

The problems are primarily what happens with misbehaving programs trying to shut down. Then trying to figure out the right place to free can only add exceptions.

Constructs like this generally aren't for the well behaving, predictable case.