Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General Discussion » View Thread |
Messages 1 to 6 of 6 total |
Help with a memory leak |
Fri, Jul 20 2007 12:50 PM | Permanent Link |
Jon Lloyd Duerdoth | I've have had the following memory leak for some time and
just can't track it down ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ An unexpected memory leak has occurred. The unexpected small block leaks are: 1 - 12 bytes: TIdThreadSafeInteger x 1 21 - 28 bytes: TIdCriticalSection x 2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I've even stripped the project file down to: ReportMemoryLeaksOnShutdown := DebugHook <> 0; Application.Initialize; Application.Run; The project terminates immediately (of course) but I still have the memory leak. Any suggestions would be appreciated. Jon |
Fri, Jul 20 2007 1:42 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Jon
Just in case you hadn't guessed then going by the names its something to do with Indy, and unless Indy has improved a lot tracking stuff down in there is a nightmare. Having said that I'm having my own nightmare tracking down a TStringList leak, and can't get FastMM's diagnostic report to be generated. Roy Lambert |
Fri, Jul 20 2007 2:01 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Jon
Googling for help in finding my leak I came across http://groups.google.com/group/borland.public.delphi.language.basm/browse_thread/thread/4810f81f8e8a8d1e/05d13169e9337011?lnk=st&q=(fastmm+and+debugmode)+group%3Aborland.public.delphi.*&rnum=4#05d13169e9337011 Roy Lambert |
Fri, Jul 20 2007 9:36 PM | Permanent Link |
Lance Rasmussen Jazzie Software Team Elevate | I get that as well.
It's coming from Indy. Lance "Jon Lloyd Duerdoth" <jld@welshdragoncomputing.ca> wrote in message news:AFB747FD-F931-4B1D-8F87-66CBFAAA454F@news.elevatesoft.com... > I've have had the following memory leak for some time and > just can't track it down > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > An unexpected memory leak has occurred. > The unexpected small block leaks are: > > 1 - 12 bytes: TIdThreadSafeInteger x 1 > 21 - 28 bytes: TIdCriticalSection x 2 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > I've even stripped the project file down to: > > ReportMemoryLeaksOnShutdown := DebugHook <> 0; > Application.Initialize; > Application.Run; > > The project terminates immediately (of course) but > I still have the memory leak. > > Any suggestions would be appreciated. > > Jon |
Sat, Jul 21 2007 4:15 AM | Permanent Link |
Eryk Bottomley | Jon,
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > An unexpected memory leak has occurred. > The unexpected small block leaks are: > > 1 - 12 bytes: TIdThreadSafeInteger x 1 > 21 - 28 bytes: TIdCriticalSection x 2 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > I've even stripped the project file down to: > > ReportMemoryLeaksOnShutdown := DebugHook <> 0; > Application.Initialize; > Application.Run; They are resources being allocated in the initialization section of one of the Indy units and then either not being freed in the finalization section or else FastMM can't "see" them being freed. In either case it is harmless. If the entire process address space is being trashed anyway then whether these resources are explicitly freed or not is neither here nor there. Initialization sections are only called once when a unit first loads so the leak cannot accumulate (DLLs aside, which is not the case here). Eryk |
Sat, Jul 21 2007 2:41 PM | Permanent Link |
Jon Lloyd Duerdoth | Thanks everyone for the comments... nice to know
I'm not alone! Jon Eryk Bottomley wrote: > Jon, > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> An unexpected memory leak has occurred. >> The unexpected small block leaks are: >> >> 1 - 12 bytes: TIdThreadSafeInteger x 1 >> 21 - 28 bytes: TIdCriticalSection x 2 >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> I've even stripped the project file down to: >> >> ReportMemoryLeaksOnShutdown := DebugHook <> 0; >> Application.Initialize; >> Application.Run; > > > They are resources being allocated in the initialization section of one > of the Indy units and then either not being freed in the finalization > section or else FastMM can't "see" them being freed. In either case it > is harmless. If the entire process address space is being trashed anyway > then whether these resources are explicitly freed or not is neither here > nor there. Initialization sections are only called once when a unit > first loads so the leak cannot accumulate (DLLs aside, which is not the > case here). > > Eryk |
This web page was last updated on Wednesday, April 24, 2024 at 11:07 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |