A colleague raised a question that realloc does better than free + malloc because allocated memory block is never being actually shrunk and reallocations to smaller size following by reallocations to larger (but still not larger than one of the previous) do not lead to heap locks and actual underlying heap memory block reallocations. While [...]
Posts Tagged ‘memory’
Continuous realloc()
Posted: 29th September 2012 by Roman in Source, UncategorizedTags: C++, CRT, heap, memory, Source, Windows API
0
Hardware assisted memory corruption detection
Posted: 19th November 2011 by Roman in ATL, Seriously, SourceTags: ATL, corruption, debug, detection, exception, hardware, memory, protection
So you got a memory corruption issue with a piece of software. It comes in a unique scenario along the line of having a huge pile of weird code running well most of the time and then, right out of the blue, a corruption takes place followed by unexpected code execution and unstable software state [...]
DirectShow Spy: Intelligent Connect Trace, Selective Process Black Listing
Posted: 24th July 2011 by Roman in UtilitiesTags: DirectShow, filter, graph, hook, intelligent connect, memory, spy, trace
DirectShow Spy is updated with a few new features: retroactive Intelligent Connect trace log output for IAMGraphBuilderCallback-related activity process name based black list to selectively exclude processes from spying Intelligent Connect Trace The utility received a capability to read back from its own log file (DirectShowSpy.log, located typically in C:\ProgramData directory) and reconstruct graph building [...]
DirectShow Spy: Memory Allocator Properties
Posted: 5th March 2011 by Roman in UtilitiesTags: allocator, buffer, DirectShow, filter, graph, hook, memory, spy
A small update to the DirectShow Spy today: DirectShow Filter Graph Spy prints memory allocator properties as a part of graph topology trace on transition to running state. Why is that and what it is for? Filters normally agree on allocator properties (ALLOCATOR_PROPERTIES, obtained from IMemAllocator, obtained from IMemInputPin) themselves without interference from controlling application. [...]
Sharing Memory Allocators while at the same time Handling Dynamic Media Type Changes
Posted: 16th July 2009 by Roman in SeriouslyTags: allocation, DirectShow, filter, IMemAllocator, memory, performance, sharing
Sharing memory allocators between input and output pins is an important concept to keep performance of filter graph. Unlike more frequent scenario with different allocators, a filter (referred to as “middle filter” below) which has equal media types on input and output pins has an advantage to avoid memory-to-memory copy operation for every frame processed, [...]
Ahead Nero’s NeResize DirectShow Filter
Posted: 30th June 2009 by Roman in SeriouslyTags: access violation, ahead, bug, crap, crash, debug, debugger, DirectShow, filter, memory, NeResize, nero
Another example of a negligence with a cost of incompatibility and enormous amount of support time. Ahead Nero installs a number of DirectShow filters into $(Program Files)\Common Files\Ahead\DSFilter directory. One of the files is NeResize.ax and it hosts a Nero Resize filter. Let us take a closer look: CLSID: {30002E0C-C574-481E-A5DE-90AE54A79E10} (note that Nero 8 ships [...]