On Tue, Jan 29, 2019 at 08:59:30AM +0100, Dario Lombardo wrote:
> > This does not mean that there are no more memory leaks though (we have
> > pretty bad test coverage)
>
> Have you ever tried to compute the coverage with, eg., gcov/lcov? I'm
> working on it but it's still a WIP.
> There are also
On Mon, Jan 28, 2019 at 4:03 PM Peter Wu wrote:
> If you have not already, consider enabling ASAN by default in your
> development builds (cmake -DENABLE_ASAN=1). It works on Linux and macOS,
> but not with MSVC. ASAN detect memory safety issues (use-after-free,
> double-free, buffer overflows, e
Impressive achievement, Peter!
On Mon, Jan 28, 2019 at 10:03 PM Peter Wu wrote:
> This does not mean that there are no more memory leaks though (we have
> pretty bad test coverage)
Have you ever tried to compute the coverage with, eg., gcov/lcov? I'm
working on it but it's still a WIP.
There a
Nice work Peter, you’re a machine!
> On 28 Jan 2019, at 22:02, Peter Wu wrote:
>
> Hi!
>
> I am happy to share that current git master passes all tests without
> failing on memory leaks (as reported by AddressSanitizer)!
__
Hi!
I am happy to share that current git master passes all tests without
failing on memory leaks (as reported by AddressSanitizer)!
This does not mean that there are no more memory leaks though (we have
pretty bad test coverage), but at least it allows enabling ASAN without
disabling memory leak d
Still no luck fixing this memory leak... I am using Wireshark v 1.2.0 code as
a base. I have looked into tshark, file, and rawshark very closely and I
believe I am actually freeing more memory than they are, but still have not
been able to figure out why field_info associated with "ti" below i
I have been rolling my own version of "tshark" for a project. I needed to do a
few things differently, but wanted all the awesomness of the dissectors to work
for me. I have been looking at a few reported memory leaks (via Valgrind) and
there are two that are really stumping me. I am wonderin
ed with delete, new [ ] with delete [ ]
but only malloc() with free().
Andy.
To
Developer support list for Wireshark
cc
bcc
Subject
Re: [Wireshark-dev] Memory Leak
Please respond to : Developer support list for Wireshark
Sent by: wireshark-dev-boun...@wireshark.org
25/03/2009 14:2
Isn't your DLL written in C++? You're not mixing new & free are you?
Storage got with new must be returned with delete, new [ ] with delete [ ]
but only malloc() with free().
Andy.
To
Developer support list for Wireshark
cc
bcc
Subject
Re: [Wireshark-dev] Memory Lea
Have a nice day
GV
- Original Message -
From:
To:
Sent: Tuesday, March 24, 2009 9:57 AM
Subject: [Wireshark-dev] Memory Leak
> Hi all,
>
> So in my dissector, i call a dll that allocates memory for information to
> be returned back for output, but when i try and free the m
brary/ms235460(VS.80).aspx
Have a nice day
GV
- Original Message -
From:
To:
Sent: Tuesday, March 24, 2009 9:57 AM
Subject: [Wireshark-dev] Memory Leak
> Hi all,
>
> So in my dissector, i call a dll that allocates memory for information to
> be returned back for output, but wh
Hi all,
So in my dissector, i call a dll that allocates memory for information to be
returned back for output, but when i try and free the memory, i get an error. I
was wondering what the scope of the memory would be and where i should free it,
maybe i'm freeing it wrong. I allocate it in my dl
Didier wrote:
>>> (aka sizeof structure g_mem_chunk) not the allocated memory as with
>>> gtk1. You have to call g_mem_chunk_free for each allocated chunk.
>
>> I'm not seeing that leak, at least on Linux. Each atom is 131,072 bytes big.
>>> Reloading a 170,000 packet trace file many times doe
> > (aka sizeof structure g_mem_chunk) not the allocated memory as with
> > gtk1. You have to call g_mem_chunk_free for each allocated chunk.
> I'm not seeing that leak, at least on Linux. Each atom is 131,072 bytes big.
> > Reloading a 170,000 packet trace file many times does not show any gro
Didier wrote:
> On Thu, 19 Jul 2007 14:16:49 -0400, Jeff Morriss wrote
>> Didier wrote:
>>> Hi,
>>>
>>> 1) It seems that since some glib 2.0 version g_mem_chunk_destroy doesn't
>>> free
>> The docs certainly seem to indicate that the memory should actually
>> be freed:
>>
>> http://www.gtk.org/api/
On Fri, 20 Jul 2007 03:11:20 +0200, Didier wrote
> On Thu, 19 Jul 2007 14:16:49 -0400, Jeff Morriss wrote
> > Didier wrote:
> > [That's not to say I don't see memory usage growing when I reload a
> > capture file, but I'm not convinced this is the source.]
> Attached a small patch which replace g
On Thu, 19 Jul 2007 14:16:49 -0400, Jeff Morriss wrote
> Didier wrote:
> > Hi,
> >
> > 1) It seems that since some glib 2.0 version g_mem_chunk_destroy doesn't
> > free
>
> The docs certainly seem to indicate that the memory should actually
> be freed:
>
> http://www.gtk.org/api/2.6/glib/glib-Memor
Didier wrote:
> Hi,
>
> 1) It seems that since some glib 2.0 version g_mem_chunk_destroy doesn't free
> its memory and from glib source code I would say it's not a bug but a
> feature... The biggest issue is in file.c, eg reload (CTRL+R) many time a big
> file.
The docs certainly seem to indicate
Hi,
1) It seems that since some glib 2.0 version g_mem_chunk_destroy doesn't free
its memory and from glib source code I would say it's not a bug but a
feature... The biggest issue is in file.c, eg reload (CTRL+R) many time a big
file.
2)COPY_ADDRESS is still misused in a lot of place it g_mallo
19 matches
Mail list logo
