Re: problem using INTERFACE_BUFFER

[email protected] Mon, 23 Dec 2002 10:32:10 -0600
Newsgroups gmane.mail.eps
Organization Inter7 Internet Technologies, Inc.
Message-ID <[email protected]>
Yeah.  Version 1.4 fixes all allocation/deallocation errors, as well
as doing away with the internal MEM_DEBUG stuff (uses an external
library now).  I'll put 1.4 up pre-release.  It's not done yet, but it
compiles and works.

Check the link periodically http://www.inter7.com/eps/eps-1.4.tar.gz
I should have it up in an hour or so.

Good luck!

David Relson wrote:
> 
> Greetings,
> 
> I'm experimenting with INTERFACE_BUFFER, turned on MEM_DEBUG to verify
> storage is being properly freed up, and have run into a snag.
> 
> I'm using a line_t struct, adding the email to it using line_inject(),
> printing the message (usign eps_next_header(), eps_next_line(),
> mime_next_header(), mime_next_line()), and at the end calling line_kill to
> free the line_t struct.  The setup and printing work fine, but the cleanup
> at the end gives message:
> 
>         "MEM_DEBUG: MFREE: Unknown allocation space at 0x804e5d8 (Searched 1 records)"
> 
> Looking at the code, I see line_inject() uses realloc() to increase text
> storage allocation and line_kill uses mfree().  The mixture of storage
> allocation styles (libc and user) seems to be at issue.
> 
> I've taken a look at mrealloc() which would seem to be the logical answer,
> but it doesn't seem complete.
> 
> I'm using eps-1.2.  Are there any patches for it?  Is there a newer version
> available?
> 
> Thanks.
> 
> David

-- 
mailto:[email protected]
Matt Brookings - Chief Technical Officer
Inter7 Internet Technologies, Inc.
www.inter7.com - 847-492-0470
Prices at http://www.inter7.com/prices