Free memory allocator software for linux

Memcheck provides the ability to fault on pointer overrun (read or write) or freed pointer deference (read or write), logs double free and realloc of already freed pointers and memory not freed on exit, checks for pointer underrun on free and realloc, optionally reverses the behavior of overrun and underrun, "churns" reallocations to always return a different pointer, and logs pointer overruns instead of faulting.
It has a very small performance impact, with the tradeoff of a large memory footprint. It includes a validation test suite to verify correctness of the library. It is tested on a variety of architectures, including Alpha, ARM, HPPA, PPC, ix86, IA64, rs6000, S390, SPARC, and SPARC64.
It is tested on a variety of platforms, including OSF, FreeBSD, NetBSD, OpenBSD, Linux, HP/UX, Mac OSX, AIX, SCO, and Solaris.
Enhancements:
- Some missing backtraces were fixed.
- An atexit replacement was implemented to catch allocations that are freed by previously installed atexit handlers.
- Deeper backtraces are stored, and internal recursions are handled.

Gnome Memory Blocks project is a concentration game for GNOME.

This is GNOMEs version of the `memory blocks game originaly come from Semantec game pack for Win-3.11

vtmalloc is a fast memory allocator for multi-threaded applications and Tcl. vtmalloc project provides low contention and the ability to return memory to the system.
Tcl
Replace exiting tclThreadAlloc. in the Tcl distribution and recompile with
--enable-threads option. Or use LD_PRELOAD=tclThreadAlloc.so before loading your application.
There is command Tcl_VTMallocCtlObjCmd which can be used in application to force deallocating global pages as well.
To use it in your Tcl program, link it with libvtmalloc.so and execute
extern Tcl_ObjProc Tcl_VTMallocCtlObjCmd;
Tcl_CreateObjCommand(interp, "vtmalloc_ctl", Tcl_VTMallocCtlObjCmd, NULL, NULL);
Enhancements:
- Greatly improved speed and memory usage.

The Linux Memory Game project is a childrens (and adults) game based on the card game.
The Linux Memory Game is an X11 game using GTK+ library for children ages 3 and up. It is a lot more than the card game "Memory".
It has five skill levels, the higher ones are challenging to adults as well. Additionally, one can choose from the menu to match 2 cards or 3 cards, or match different cards.
This last "different card" mode can be a very good teaching tool for teaching languages, concepts, or association.
Main features:
- Extensible - add new images yourself without having to make changes to the program.
- Five skill levels appropriate for the youngest and the ones with the best brains.
- Can play two card matching or three card matching (more challenging!)
- Can set to match different cards. This can be used with apropriately designed pictures to teach children (or adults) words, concepts, or another language.
Enhancements:
- Fixed overflow bug in pixmaps_jump.

Guarded Memory Move project gets handy when you have to study buffer overflows and you need to catch them together with a "good" stack image. When a stack overflow has been exploited, the back trace is already gone together with good information about parameters and local variables, that are of vital importance when trying to understand how the attacker is trying to work out the exploit. The GMM library uses dynamic function call interception to catch the most common functions that are used by attackers to exploit stack buffers.
The GMM library uses the LD_PRELOAD capability and offers two services to the user. First of all, it avoids buffer overflow to allow the attacker to execute shell-code on your machine. Second, in case where an exploit is detected, the stack content is saved and a segmentation fault is triggered. The resulting core dump will then have all the necessary information to debug the exploit and fix the software. Internally, the library insert itself between the application and the glibc library and intercept functions that might lead to buffer overflow exploits. Before calling the glibc core function, the GMM layer saves part of the stack frame above the caller to a temporary location in its frame.
It also stores the previous three return addresses in its local storage before calling the glibc core function. When the core function returns, the GMM code samples again the previously recorded return addresses and, if they differ, it restores the previously saved stack frame and issue a segmentation fault. This with a clean stack frame, so that it can be inspected with a debugger. While other solutions exist to detect buffer overflow exploits, like for example StackGuard and StackShield, those differs from GMM in many ways. They live as gcc patches and do require you to rebuild your application to use their functionalities. The good of this approach is that every single function is protected against buffer overflows.
The bad of this solution is that every single function is protected against buffer overflows. That is, performance regression on the whole application, even if this is not really a huge problem when hunting for buffer overflows. Another solution similar to GMM is LibSafe, but it does not save and restore the stack frame by making it unusable for debugging. But lets see how GMM differs from the above listed solutions. First of all, GMM works everywhere there are stack frames and the gcc and glibc duo. That means that it is not limited to i386 only. And now the real reason for the GMM existence.
Enhancements:
- GCCs __builtin_return_address and __builtin_frame_address seems to return garbage instead of NULL at the last frame. This release fixes the problem.

Widget libraries have now been developed and used for years. In all these libraries, widget instances require computer memory. But this memory is not really required, We have implemented a widget library to prove that it is possible to use zero bytes of memory per widget.
In such a library, there is no widget reference, so widget programming is easier even in a low level language such as C. Programs are more robust because they do not use pointers, make no memory management and do not translate data between application and widget.
To set the attributes of a widget, it is not possible to use the widgets pointer so a current state is used as in OpenGL. Most classic widgets were integrated into the library, and it is possible to integrate widgets of all kinds without any problem.
This library license is the GNU GPL. Beware: it is alpha software. It works but the API is not yet stable.
Main features:
Base widgets:
- text, text_editable, int, int_editable,
- anchor,
- button, tearoff, button_with_accelerator,
- image, image_from_file,
- scrollbar2, scrollbar_vertical, scrollbar_horizontal,
- toggle (bit or int or char) with or without label. Same for radio button. Really easy to use.
Container widgets:
- window, window_drag, window_popup_right, window_popup_bottom
- anchor_box,
- box_horizontal, box_vertical, box,
- decorator,
- notebook,
- scrolledview (can contains billions of children)
- viewport
- table, table_with_width,
- void, if, popup : base system to make transient widgets. The menu are constructed with "popup"
Composite widgets:
- alert (container),
- message (container),
- filechooser,
Widget attributes:
- Choice of the focus group.
- Width: padding, border, focus
- Expand: vertical, horizontal
- Alignment: vertical, horizontal
- Font: family, size, weight, style
- Geometry: x, y, width, height
- Window auto resize
- Sensibility (to overide the value computed automaticaly)
- Debug level
Other features:
- a drag and drop working only inside the application.
- fully working text cut and paste (UTF8 or not).
- simple animation possible.
- the library runs a web server allowing to debug.
- accelerators. If a modifier key is pressed, a list of short-cut with this key is displayed in a bubble tip.
Enhancements:
- Complete rewrite of the kernel API, in order to have :
- The library can now be updated without recompiling external code

Monkeys Memory is an implementation of the classic game of memory. Classic Game of Memory written in mono where you can play against other people (on the same computer, network game is not implemented jet) or against Computer (there is 2 type of computer player).

There is more level of game from tiny level to very big one.

The goal of RUMT is to check the memory of a computer over a long period of time and almost-real load conditions without having to interrupt the services.

RUMT exploits the possibility of some Unix kernels to selectivly disable some memory areas while still accessing them through the /dev/mem device. The principle of RUMT is to write pseudo-random data in these disabled memory areas, and later check them. This principle and the original code for the deterministic pseudo-random generator are from David Madore.

This distribution contains another variant on the same theme: URUMT allocates a large chunk of memory, locks it in memory using the mlock(2) system call, and scans /dev/mem to find where in physical memory the allocated area is. Then it continuously runs the same tests in that memory.

URUMT can not be used to test a particular area of memory: the kernel will give it whatever physical memory it feels like. But URUMT can be restarted now and then, hopefully getting different physical memory each time.

This is perfect if you suspect you have bad bits, but do not know at all where they are. Once you have sighted the bad bits, you can use a plain RUMT to test more extensively the neighborhood.