[Alex Lindberg <alindber@xxxxxxxxx>]

Win32 in my case is XP + SP3.

It stays in memory (GUI or tshark version) so that when I run another compile on windows, during the copy of the exe to wireshark-gtk, the build fails with "unable to copy" message.  If I kill wireshark.exe from the task manager, all is good.

If I build the standard WS 1.6.0, all is good, but not with my code included.

If I run the tshark from the commandline to read a file, it will not quit until I kill tshark.exe from the task manager.  (^C will not kill it)

My custom build also registers a wtap_register_<protocol> block to read a custom file structure.

I removed the wtap_register_<protocol> from my code with the same results.

Thanks as always.
Alex Lindberg



--- On Tue, 8/2/11, Guy Harris <guy@xxxxxxxxxxxx> wrote:

From: Guy Harris <guy@xxxxxxxxxxxx>
Subject: Re: [Wireshark-dev] Freeing memory when quitting Wireshark
To: "Developer support list for Wireshark" <wireshark-dev@xxxxxxxxxxxxx>
Date: Tuesday, August 2, 2011, 3:21 PM

On Aug 2, 2011, at 12:21 PM, Alex Lindberg wrote:

> When I quit a custom build of Wireshark (Win32), although the application disappears from the desktop, it remains in memory.

What do you mean "remains in memory"?

Perhaps Windows - which probably means Windows NT these days, with XP and later being the predominant desktop versions - doesn't have the same model as UN*X, where

    1) when a process exits, "anonymous" pages in the process address space, as allocated by malloc() and the like, simply disappear without having to be explicitly unallocated;

    2) file-backed pages, such as pages from the executable image and dynamically-loaded code (shared libraries, etc.), remain in memory (but aren't wired into memory, so they're reused if you use the executable or the dynamically-loaded code again and are still in memory, but their page frames can be reused for other purposes);

but I doubt it does.  This means that there is no need to explicitly free memory when Wireshark (or any other program) exits - it gets freed (and more quickly than if it were explicitly freed).
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe