Wireshark-users: Re: [Wireshark-users] bug in sub-allocator emem.c - guard pages cause unnecessar
Well, that's a "security feature" (some would call it band-aid
security). That's why its's there even if it costs a lot. It's work is
to be able to detect memory corruption conditions (and yes it does, we
are still getting and fixing of crashes reported by this (buffer
overflows) ).
But on the other hand you're right, these increase the amount of
memory we use by a lot.
I've been thinking of some changes that can be made:
- have env variables to enable/configure/disable its use (been, BTW,
protective by default).
- Use 1 word PRBS canaries placed between a configurable num of allocs
instead of the large unconditional ones.
I'd want to discuss with others an architectural change to emem to
allow emem to work this way (and distribute with it enabled) but to be
able to use emem for what it was originally meant (get rid of 99% of
our sys-calls, avoiding leaking, been much faster than using malloc).
\Lego
On Fri, Aug 8, 2008 at 6:09 PM, bob frazier <bfrazier@xxxxxxxxxxx> wrote:
> for very large files (1 hour streaming video capture) tshark will crash when doing
> analysis of RTP packets (let's say you're extracting specific data and filtering the
> output and generating text). On FreeBSD there is an unhandled 'out of memory' exception
> that causes the crash. This crash can be prevented (at least to some extent) by
> disabling "guard pages" and "canaries" in emem.c, then doing a full re-build
> (incremental build was insufficient).
>
> The problem appears to be a serious virtual address fragmentation problem, since when
> the crash happens the virtual address space is >2Gb, while actual memory used is in the
> neighborhood of 200Mb. Removing guard pages and canaries seems to resolve the problem.
>
> tshark command line looked like this (on a >17Gb capture of RTP/RTSP/RTCP data)
>
> tshark -r test.pcap -p -R"(ip.dst==192.168.1.100 && rtp.p_type==96)" -Tfields
> -eframe.number -eframe.time_relative -ertp.p_type -ertp.extseq
>
>
> Similar problems also exist in the WIN32 version. Modifying the code to compile the "no
> guard page" 'malloc' sections (in lieu of 'VirtualAlloc' + 'VirtualProtect') for WIN32
> also resolves THAT problem.
> _______________________________________________
> Wireshark-users mailing list
> Wireshark-users@xxxxxxxxxxxxx
> https://wireshark.org/mailman/listinfo/wireshark-users
>
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
