Wireshark · Wireshark-dev: Re: [Wireshark-dev] Problems with epan\oids.c

[Graham Bloice <graham.bloice@xxxxxxxxxxxxx>]

Peter Johansson wrote:
> 2008/3/17, Peter Johansson <peterjohansson73@xxxxxxxxx 
> <mailto:peterjohansson73@xxxxxxxxx>>:
>
>     2008/3/17, Bill Meier <wmeier@xxxxxxxxxxx
>     <mailto:wmeier@xxxxxxxxxxx>>:
>
>         Peter Johansson wrote:
>         > 2008/3/13, Luis EG Ontanon <luis@xxxxxxxxxxx
>         <mailto:luis@xxxxxxxxxxx> <mailto:luis@xxxxxxxxxxx
>         <mailto:luis@xxxxxxxxxxx>>>:
>         >
>         >     On Thu, Mar 13, 2008 at 2:38 PM, Stig Bjørlykke
>         <stig@xxxxxxxxxxxxx <mailto:stig@xxxxxxxxxxxxx>
>         >     <mailto:stig@xxxxxxxxxxxxx <mailto:stig@xxxxxxxxxxxxx>>>
>         wrote:
>         >      >  I suppose we have to leave them allocated if we don't
>         know how
>         >     libsmi
>         >      >  is compiled?
>         >      >  I have almost no experience on Windows, do we compile
>         this our self?
>         >
>         >     I compiled it, I just made changes to the makefile (and
>         build only the
>         >     dll), I have no clue whether HAVE_VASPRINTF was defined
>         or not.
>         >
>         >
>         > Did you compile it using MSVC 6? Could this then be of the
>         same type of
>         > issue that is with adns, hence it is required to recompile
>         libsmi too if
>         > using another compiler for Wireshark on Windows than MSVC 6.
>         Developer
>         > Studio 2005EE for instance?
>         >
>
>         My 2 cents ....
>
>         1. As noted previously: the problem is that there are (in effect)
>            malloc(...) statements in libsmi which allocate storage and
>         free(...)
>            statements in oids.c to free that storage.
>
>            This is a non-starter on Windows if libsmi.dll is linked
>            against a different msvcrt than wireshark. (Think allocating
>            memory in one heap and trying to free it in a completely
>            different heap). This is the case if Wireshark is built,
>            for example, using vc 2005EE(using msvcr80.dll) since
>            our version of the Windows libsmi is currently built
>            with vc6 (using msvcrt.dll).
>
>            (If this 'gotcha' isn't mentioned someplace in the
>         developer docs, it
>             probably should be. If needed, I'll add something about the
>             whole issue of using mixed run-time MSVCRT libraries
>             with Wireshark on Windows).
>
>         2. Possible solutions:
>
>            a. (As a temporary workaround for anyone wishing to able to
>               build a working Wireshark with other than vc6 which uses
>               the current libsmi: Remove the free(...) statements in
>         oids.c).
>            b. Compile libsmi as part of the build process (like adns &
>         etc).
>               (It would be really nice not to have to do this ....).
>            c. Looking at the smi code: there's a smiFree function in
>               the smi file utils.c which seems like it might be
>               just what is needed.
>               However there's something to do with an
>               #ifdef HAVE_DMALLOC_H which I don't altogether
>         understand. Maybe
>               this can be ignored since I'm pretty sure that our vanilla
>               Windows build done using the makefile mentioned previously
>               does not define this symbol.
>               If so, a solution might be (on Windows only):
>               1. exporting smiFree from libsmi (and then rebuilding
>                  the library);
>               2. adding an extern smiFree(void *ptr) to oid.c;
>               3. changing the various free(...) statements in oids.c to
>                  smiFree(...).
>
>                  (Obviously it would be much cleaner if smiFree were
>         available
>                  as part of the API so that it could be used on any
>                  platform. Or: maybe there's another better way .....
>                  Possibly we could ask upstream if something can be done).
>
>
>               Also: I don't think it makes any difference whether
>               HAVE_VASNPRINTF & etc were defined when the Windows libsmi
>               was built.
>               Whether a library version of vasnprintf  or the libsmi
>               version is used, storage is allocated and would need to
>         be freed.
>
>
>         Thoughts ??
>
>
>         Bill
>
>      
>      
>     I believe that adding information to for instance README.developer
>     on what is required to be done by developers on Windows due to the
>     mix of msvcr80.dll and msvcrt.dll would be good. Would you (Bill)
>     please add something in line with what you wrote above?
>      
>     Personally I would want to go with 2c (for adns as well) since it
>     is then possible to debug even this code. The pre-compiled
>     libraries adns and smi will probably continue to generate problems
>     since Windows based developers probably tend to shift more and
>     more from VC6 to any of its successors (especially 2005EE).
>     With adns it should be easier than with smi since adns at least
>     comes with build support for Windows. But there is no such thing
>     for smi. I guess that's why it was added already compiled since
>     nobody actually wants to maintain the makefiles of a third party
>     library.
>      
>     However, another approach might be possible here. One where nobody
>     needs to maintain (at least not continuously) the makefiles for
>     these libraries:
>     We could provide precompiled versions of both adns and smi using
>     different versions of Visual Studio and Developer studio. It would
>     then be possible to link the binaries with whatever version that
>     matches the MSVC_VARIANT variable (config.nmake). Does anyone know
>     if there are more versions of the MS VC runtime library than
>     msvcr80.dll and msvcrt.dll? Is perhaps msvcrt.dll required only by
>     VC6 and msvcr80.dll required for the rest of them?
>      
>     / Peter
>
>
>  
> When it comes to adns, the only thing that prevents it from being 
> included in the ordinary build (apart from adding it to the Wireshark 
> makefiles) is that a file in the adns Win32 distribution contains 
> references to the "program files" directory on Windows spelled in some 
> language. The file in question is adns_dll.dep (located in 
> adns-1.0-win32-05\adns_win32\adns_dll). All lines that begin 
> with "..\..\..\..\..\..\programfiler" can be safely removed from the 
> adns_dll.dep file (it seems to me that they are there only to trigger 
> a re-compilation if, lets say, Windows update provides new versions of 
> the SDK files). Perhaps we could ask of Jarle (jgaa) Aase to remove 
> these lines from his distribution?

See also http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2075 for an 
attempt to fix the adns issue with versions other than MSVC 6.  If we 
are going to contact jgaa, updating his makefiles to allow CFLAGs to be 
passed in would be nice as well.

--
Regards,

Graham Bloice