Bill Meier wrote:
Jeff Morriss wrote:
Bill Meier wrote:
I've found at least one case wherein se_alloc'd memory
is referenced after it's been freed. (I think this case just happens
to work because the memory wasn't yet reassigned).
I was contemplating adding an optional
Jeff Morriss wrote:
Bill Meier wrote:
Jeff Morriss wrote:
Bill Meier wrote:
I've found at least one case wherein se_alloc'd memory
is referenced after it's been freed. (I think this case just happens
to work because the memory wasn't yet reassigned).
I was contemplating adding an
Bill Meier wrote:
Even tho (in theory) most of the GMemChunks have been fixed, I'm still
looking at a large memory leak someplace when I repeatedly reload a
iax2/h223 capture file.
Related to defragmentation ???
OK: (blinking in the bright sunlight as I emerge to the surface from the
Bill Meier wrote:
I've found at least one case wherein se_alloc'd memory
is referenced after it's been freed. (I think this case just happens
to work because the memory wasn't yet reassigned).
I was contemplating adding an optional memory-scrubber to ensure that
we're not doing that:
Jeff Morriss wrote:
Bill Meier wrote:
I've found at least one case wherein se_alloc'd memory
is referenced after it's been freed. (I think this case just happens
to work because the memory wasn't yet reassigned).
I was contemplating adding an optional memory-scrubber to ensure that
: Re: [Wireshark-dev] g_mem-chunk_destroy does not free memory
for GLib 2.8
Kovarththanan Rajaratnam wrote:
Hey Bill,
Is there any reason why we couldn't use se_alloc and friends? This
should be faster now that we're defaulting to _not_ use canaries for
seasonal memory.
Using se_alloc
Anders Broman wrote:
Hi,
Should fixes to these probleems be backported to 1.2.3?
Regards
Anders
Yep: I'll add them all to the roadmap soon (after I've made sure I'm OK
with everything).
Even tho (in theory) most of the GMemChunks have been fixed, I'm still
looking at a large memory leak
?
Regards
Anders
-Original Message-
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Bill Meier
Sent: den 11 oktober 2009 15:32
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] g_mem-chunk_destroy does not free
Hey Bill,
Bill Meier wrote:
The following are OK:
./epan/proto.c:455 ; Used for all GLib versions: mem leak @
; proto_cleanup ?
; Benign since proto_cleanup called only @ exit ??
This definately looks like a memleak. I've switched over to
Hey Bill,
Bill Meier wrote:
If there is no simple way to free up what may be an array of many
multiple slices, I'm inclined to replace the use of GMemChunk (at least
for those cases) by the use of GArray.
After a quick look, one concern I have is about constantly extending a
GArray thus
Kovarththanan Rajaratnam wrote:
Hey Bill,
Is there any reason why we couldn't use se_alloc and friends? This
should be faster now that we're defaulting to _not_ use canaries for
seasonal memory.
Using se_alloc is the conclusion I came to (when the code frees
GMemChunk memory
Bill Meier wrote:
snip
If there is no simple way to free up what may be an array of many
multiple slices, I'm inclined to replace the use of GMemChunk (at least
for those cases) by the use of GArray.
After a quick look, one concern I have is about constantly extending a
GArray thus
While working on bug #2375 I've found out (the hard way) what Didier
reported in bug #3813:
... in recent glibs g_mem_chunk_destroy doesn't free [memory]
I'm guessing that this is true for any GLib 2.8 (altho I haven't
checked) since GSlice was implemented in GLib 2.10.
This means that
13 matches
Mail list logo
