MALLOC_DEBUG=15 debugging library

Note: This debugging tool is highly experimental. If you don't understand the 
following description, you probably don't want to use it. All the usual precautions 
must be taken.

A new debugging feature is included in the enclosed copy of a debugging libroot. 
This takes advantage of a GCC feature where the compiler inserts code to check 
every memory access.  This allows the code to break into the debugger immediately 
before the offending memory access instead of some several thousands of lines 
of code later, and can catch read as well as write accesses.  

To use it:
-  copy the experimental libroot.so_debug into /boot/beos/system/lib 
	as libroot.so (replacing the original libroot.so). Make sure you make a 
	backup copy of libroot.so and restore it when you are done debugging.
- re-compile the application, with special compile flags: 

	-fcheck-memory-usage -D_KERNEL_MODE

	(the -D_KERNEL_MODE is used to not produce inline assembler 
	for find_thread(NULL).  If you use the -fcheck-memory-usage with 
	inline assembler, it will generate a compiler error).  It is ok to 
	mix and match modules that have been compiled with and without this 
	flag.  

- link your application against the debugging libroot (this will 
	happen automatically if you placed it into /boot/beos/system/lib). If you 
	don't do this step right, you will get a ton of linker errors

In general, using it should double the size of your binary (compared to a binary 
without debugging dwarf info, with dwarf info enabled the size increase will be 10% 
or so).


To debug your app, in Terminal do:

export MALLOC_DEBUG=15
launch your app from command line

You may also use bdb - in Terminal do:
export MALLOC_DEBUG=15
launch bdb from the command line with the debugged app as a command line argument

Note that the MALLOC_DEBUG slider in bdb has not been updated yet to 
support MALLOC_DEBUG15 so you will need to use the Terminal to set it.

You will notice some slowdown in your application but in general the 
app should still be pretty usable. Stepping in bdb will be a little awkward 
because bdb will often take you into the debugging code (which is inlined 
into the binary) but you may just step out and continue.

When a memory access is detected to unmapped memory (either read or a write), you will 
break into the debugger (bdb or Terminal) right at the spot where the access happened.

Currently this only works on heap allocated objects, stack allocated 
checking coming soon.

