-----Ursprungligt meddelande-----
Från: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] För Jeff Morriss
Skickat: den 9 oktober 2009 22:06
Till: Developer support list for Wireshark
Ämne: Re: [Wireshark-dev] New packet list - out of memory?
Anders Broman wrote:
>>> 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.
>
>True, especially at the rate we're using memory :-)
>
>> 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?
>
>Well, you know, we could only use the canary allocator when we think we
>might stomp on the memory. Hmmm, I guess that logic doesn't work too
>well, huh? ;-)
>
>My initial thought had been something like: only use the canary-less
>allocator for stuff that we allocate a LOT of or core-stuff (and make
>dissectors use the canaries on the assumption we trust them less). I'm
>not sure that makes a lot of sense either, though...
>
>I just keep thinking of a time a while ago where we saw quite a lot of
>dissector bugs due to memory (canary) corruption. Apparently most of
>those were ep_ allocations. Maybe you're right that just doing it on
>the buildbot would work; keeping it on during development work would be
>a good practice too.
I thought about a define/switch DEVELOPMENT/PRODUCTION
But I'm not sure it's a good idea. You might want good performance from the
development build and it's easy to forget about these kind of things.
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
