Difference: UsingMemento (7 vs. 8)

Revision 82020-02-06 - RobinWatts

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

Memento

Line: 89 to 89
 standard malloc and returns chunks itself), then there are some things to note:
Changed:
<
<
  • If the secondary allocator gets its underlying blocks from calling
malloc, then those will be checked by Memento, but 'subblocks' that are returned to the secondary allocator will not. There is currently no way to fix this other than trying to bypass the secondary allocator. One way I have found to do this with the chunk allocator is to tweak its idea of a 'large block' so that it puts every allocation in its own chunk. Clearly this negates the point of having a secondary allocator, and is therefore not recommended for general use.

  • Again, if the secondary allocator gets its underlying blocks from
calling malloc (and hence Memento) leak detection should still work (but whole blocks will be detected rather than subblocks).

  • If on every allocation attempt the secondary allocator calls into
Memento_failThisEvent(), and fails the allocation if it returns true then more useful features can be used; firstly memory squeezing will work, and secondly, Memento will have a "finer grained" paranoia available to it.
>
>
  • If the secondary allocator gets its underlying blocks from calling malloc, then those will be checked by Memento, but 'subblocks' that are returned to the secondary allocator will not. There is currently no way to fix this other than trying to bypass the secondary allocator. One way I have found to do this with the chunk allocator is to tweak its idea of a 'large block' so that it puts every allocation in its own chunk. Clearly this negates the point of having a secondary allocator, and is therefore not recommended for general use.

  • Again, if the secondary allocator gets its underlying blocks from calling malloc (and hence Memento) leak detection should still work (but whole blocks will be detected rather than subblocks).

  • If on every allocation attempt the secondary allocator calls into Memento_failThisEvent(), and fails the allocation if it returns true then more useful features can be used; firstly memory squeezing will work, and secondly, Memento will have a "finer grained" paranoia available to it.
 

Usage with C++:

Line: 120 to 106
  or
Changed:
<
<
2) Build memento.c as normal with the C compiler, then from any one of your .cpp files, do:
>
>
2) Build memento.c as normal with the C compiler, then from any one of your .cpp files, do:
  #define MEMENTO_CPP_EXTRAS_ONLY #include "memento.c"

In the case where MEMENTO is not defined, this will not do anything.

Changed:
<
<
Both Windows and GCC provide separate new[] and delete[] operators for arrays. Apparently some systems do not. If this is the case for your system, define MEMENTO_CPP_NO_ARRAY_CONSTRUCTORS.
>
>
Both Windows and GCC provide separate new[] and delete[] operators for arrays. Apparently some systems do not. If this is the case for your system, define MEMENTO_CPP_NO_ARRAY_CONSTRUCTORS.
 

Getting better stack backtraces

Line: 159 to 142
  Even more unfortunately, pthreads gets confused by fork, and so any use of pthread mutexes, semaphores etc, even in single threaded programs will break.
Changed:
<
<
To work around this in gs, build with MEMENTO_SQUEEZE_BUILD defined. This protects various bits of code.
>
>
To work around this in gs, the gx_ functions that deal with threading and locking etc are nobbled, in that they check for Memento_squeezing() and don't do anything. (Previously we relied on MEMENTO_SQUEEZE_BUILD being defined at build time, but this is no longer required).
  Then select the allocation event you would like to start squeezing at.

For instance:

  • ./autogen.sh
Changed:
<
<
  • make memento XCFLAGS="-DMEMENTO_SQUEEZE_BUILD"
>
>
  • make memento
 
  • MEMENTO_SQUEEZEAT=1 membin/gs -sDEVICE=ppmraw -o /dev/null examples/tiger.eps > squeeze 2>&1 &

This will then run away in the background testing each possible exit route from the code, with the results going into squeeze.

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright 2014 Artifex Software Inc