Peter Johansson wrote:
> 2008/3/13, Luis EG Ontanon <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>:
> 
>     On Thu, Mar 13, 2008 at 2:38 PM, Stig Bjørlykke <[EMAIL PROTECTED]
>     <mailto:[EMAIL PROTECTED]>> 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

_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Reply via email to