> Graham Bloice wrote:
>
> > I wouldn't be surprised if it is the DNP3 dissector,
>
> It probably is.
>
> If it is, the problem is that the data for the tvbuff for the
> reassembled chunks starts with the *second* byte of the reassembled
> data, so that when g_free() is called with the pointer to the data in
> the tvbuff, the argument doesn't point to the beginning of the
> mallocated chunk of data, so it frees up a bogus pointer. In OS X, I
> get a lot of warnings about attempts to free a non-mallocated pointer;
> in other OSes, it might cause a crash, if free() (which g_free() calls)
> doesn't check for a non-mallocated pointer.
>
I'll try to have a look at this.
> > as I mentioned when I
> > sent it to the list for some other folks who were interested in
> developing
> > it, the DNP3 dissector really isn't fit for production use yet.
>
> Should we remove it from epan/dissectors/Makefile.common then? In fact,
> should we adopt that as a general policy for dissectors people send to
> the list with a "not really done yet" comment - add them to the SVN
> tree, so they're available for developers working from SVN, but don't
> add them to Makefile.common (doing so also means they won't be in the
> source tarball)?
Probably a good idea. As I mentioned, I have done some further work on it,
that I'll submit to the list.
>
> Note that it should also, after allocating the buffer, use the
> CLEANUP_CB_PUSH() macro defined in epan/exceptions.h, so that if an
> exception is thrown fetching data to fill up the buffer, g_free() is
> called on the allocated buffer (rather than leaking the buffer);
> CLEANUP_CB_POP should be called after the buffer is filled.
>
I'll look at that as well.
Graham Bloice