[Winpcap-users] Problem Freeing Array Returned by pcap_list_datalinks

[Yaser Zhian]

Gianluca Varenni wrote:
>> Guy Harris wrote:
>>> Yaser Zhian wrote:
>>>
>>>> The following code also generates the same failure:
>>>>
>>>>  int * dltlist = 0;
>>>>  int r = pcap_list_datalinks (m_capturehnd, &dltlist);
>>>>  free (dltlist);
>>>>
>>>> The problem occurs in the free() call. Am I doing something wrong?
>>>
>>> No.
>>>
>>> That code should work.  If it doesn't work, it's either
>>>
>>>     1) a bug in WinPcap;
>>>
>>>     2) a bug in the C runtime;
>>>
>>>     3) possibly a result of WinPcap being built for a different version
>>> of the C runtime than your application (so that the version of malloc()
>>> called by pcap_list_datalinks() doesn't match the version of free()
>>> called by your application), but I'm not an expert in the MSVC++ C
>>> runtime so I don't know whether that could or would be the case (UN*X C
>>> runtimes tend not to come in as many flavors and tend not to have that
>>> particular problem).
>>>
>>
>> Thanks for the quick reply.
>>
>> I guess the 3rd scenario is more likely than the first two. And I
>> guess I'd have to build WinPcap from source, don't I?
> 
> I can confirm that the problem is exactly 3). And recompiling WinPcap
> doesn't help a lot, in the sense that in any case you'd need to
> recompile a different version of wpcap.dll for *every* C-Runtime you are
> using (and this means debug and release, single threaded, multithreaded,
> multithreaded DLL, bla bla bla).
> 

By the way, do you have any idea whether this is a real problem
(i.e. the memory won't be correctly released) or it's just something
that the VC memory leak checker would complain because it has no
track of the block's allocation?

Is there a way to test this (to see whether it's a real leak)?

> This is a known problem with malloc/free's and the microsoft libraries:
> you should use malloc and free coming from the same C-runtime. Basically
> the rule is to allocate and free memory in the same module (being it a
> DLL, executable or static library). Never expose an API returning some
> chunk of memory that should be later freed by some "unknown" free
> routine (free() is the C runtime one, there are a lot of other ones!!).
> Same for file descriptors (FILE*). That's one of the reasons why for
> example in libpcap/WinPcap you have pcap_findalldevs and
> pcap_freealldevs().
> 

Thanks for the illumination!

> We can discuss for hours on whether this limitation in the C-runtime
> makes sense or is brain damaged, IMHO it makes a lot of sense, and I
> consider a really bad practice to have a function  (apart malloc()) that
> returns a chunk of memory that should be freed by the caller with free().
> 

What if the library provides it's own free() function? This can be a
simple call to CRT's free() (which would be the correct one,) and
could be used on all memory allocated inside the library and
returned for the caller to free later. But I do agree that there are
already too many memory allocation/deallocation functions out there
(specially in Win32 API) and no one needs another to add to the
mess. (I can imagine a situation in a big application, that each
block of memory would have a pointer to its correct free() function
along with it, because it uses a great number of different libraries
that make use of this strategy!)

I guess there's no escaping having to call a function such as this
twice (or two different functions) once to get the size of the
required buffer, and again to actually get the data, you know like
some Win32 functions.

Thanks, and good luck!
-yzt

-- 
"Programming is an art that fights back!"