Markus Humm wrote: >> Markus Humm wrote: >> >>> My problem now is that FastMM reports a memory leak when the >>> application is terminated. >> >> The report attached says that an attempt has been detected to call >> a virtual method on a freed object. That isn't a memory leak. > > Yes I know. When I use the fulldebug switch I get was I reported here, > but when I only use the normal fastMM of BDS2006 with > ReportMemoryLeaks OnShutdown:=true then I get a messagebox showing me > some memory leaks.
So something is not freed when the instance of your client-WSocket is freed. But even the message box of FastMM should give you a hint where to search. > The amout of them is corresponding to the number > of connection closures (really wanted disconnects and disconnects due > to my testing of the keepalive feature I implemented by plugging of > the network cable). So I think these two are interrelated. > I can't > really check it, because after the full report comes up a small > window of windows is displayed that it has detected a crash in my app > and that a faul report will be created. It terminates my app. then > and writes this fastMM report into the eventlog. When you debug the application is there an exception raised on exit? -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html > >> >>> The rest of the app. works well enough, I >>> can connect, send the data etc. disconnect, connect again etc. but >>> every time I disconnect memory gets lost (some strings and something >>> unknown, but only a few bytes (always the same amount as it seems)). >> >> No idea, however most likely something in your code. > > I thought so as well, but since I haven't yet any real clue I dared to > ask here... ;-) > >> >>> My TCP-server class (TWSocket descendant) holds a reference to the >>> TWSocket as well which is explicitely set to nil when this socket's >>> OnSessionClosed is called but directly after it a FreeAndNil(self) >>> is called. >> >> What is "Self"? Why don't you call FreeAndNil(Server.ClientWSocket)? > > Ok, that would be a good thing I think but I fear it won't be the > solution. > >> Do you create the client-WSocket with a non-nil owner? > > No. Why should I? > >> How do you free the client-WSocket when the application terminates? > > I simply close it when I free the descendants instance. > >> >> Even after a socket handle is closed the socket may exist for a >> while, handled by the OS, nothing one must care about. > > Ok. I'm simply more used to the concept of a object is dead as soon as > it's freed. Only the memory allocated for it will still belong to the > program, but can be overwritten just the next second with the next > best thing... > > Greetings > > Markus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
