ronnie sahlberg wrote: > i think significant parts of the utilized memory is memory allocated > by wireshark itself for things like reassembly and state management > of protocols. > > since most se allocation is done from within a dissector > once more/most of this is converted to use emem allocators we could > maybe do something like : > > 1, set an upper limit on how much memory we allow to be allocated by > the se allocator > 2, when se_alloc is called and we have reached this limit, just > cause a new exception MemError > to cause dissection of the packet to be aborted but allow wireshark to > continue. > > this might actually work I tried something different recently, but failed to get a reliable solution (at least on Win32):
Before the loading of a packet, get the amount of free memory from the system and stop loading packets when only a specific amount is left. Depending on the threshold to stop, this ended up in: - if the threshold is too high, leaving too much memory unused - if the threshold is too low, running out of memory before the threshold triggered This may be caused by the allocation of huge amounts from the se_ and alike functions, but I guess it's caused by the unreliable amount of current free memory. I couldn't get a good clue at which point Win32 writes out memory to the swapfile, making predictions about the free memory very difficult. I could check in the code #ifdef'ed, so others can have a look and probably find a better way than I did ... Regards, ULFL _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
