Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] New packet list - out of memory?

From: "Anders Broman" <anders.broman@xxxxxxxxxxxx>
Date: Thu, 8 Oct 2009 17:11:16 +0200
 

-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Jeff Morriss
Sent: den 8 oktober 2009 15:58
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] New packet list - out of memory?

didier wrote:
>> But are canaries used at all? In my understanding without 
>> DEBUG_INTENSE_CANARY_CHECKS they are never checked and it's unset by 
>> default.
Jeff Morriss:
>
>Erm, emem_free_all() checks that the canaries haven't been corrupted:
>
>>  if (memcmp(npc->canary_info->canary[i], canary,
npc->canary_info->cmp_len[i]) != 0)
>>      g_error("Memory corrupted");
>
Jeff Morriss:
>I fixed a bug a while ago where a dissector was writing past the end of
its se_alloc()'d 
>memory:
>
>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1513
>
>I don't think we can/should turn off canaries in se_ allocations. 
>Instead we should create a new canary-less allocator.  (Not sure what
such a thing should 
>be named, of course...)

Well as I see it EP memory is not a problem we only use one chunk (10M)
During the life time of a packet so memory efficency isn't a big issue.

But when dealing with large files waisting +30% of the memory is not an
option I think.
A way to still test se_alloc() could be to let the buildbot doing fuzz
test use canaries forinstance.

I don't see that a new allocator would solve the problem, when to use
it?

Regards
Anders

 
________________________________________________________________________
___
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe