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. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
