------------------------------------------
Information about debugging spConfig-0.1.3
------------------------------------------

Segfaulting when it should be Saving?  Crashing when it should be Parsing?  
The debug info generated by spConfig is designed to help us rapidly locate 
and correct bugs and misfeatures.  One of the most useful features 
included in this library is automated debugging information, which 
compiles completely away if you want a smaller, faster application. To 
produce a debug log, all you have to do is compile with debugging enabled 
('make DEBUG=1') and add some calls to the program using it.

Debug logs produce a large amount of data, especially when set to the 
maximal level of detail.  To allow a program to operate normally with 
debugging enabled, it is possible to redirect the debugging information to 
any opened file you wish.  This is done with 
   * DEBUGFD_spconfig ( FILE*errorfile )
errorfile defaults to STDERR, which can be redirected via the standard unix
shell redirection methods ("program parameters 2> error.log").

If you don't want to capture the full debug information, you can set the 
debug threshold.  This is a value between -128 and 127, inclusive.  The 
lower the threshold, the more output you get.  The default level is 0.
to change this level, use 
   * DEBUGLEVEL_spconfig ( debuglevel )
When trying to determine what's going on and what's gone wrong, it's probably
best to use a debuglevel of -128, for the most detailed information.

That's all one needs to use to setup and capture debugging information. When
reporting problems to us, as usual, a configure file, code snippets, or full
programs that  demonstrate problems would also be quite helpful, when possible.

Please submit reports to spconfig@softpixel.com.

-------------------
spConfig and Malloc
-------------------

We intend spConfig to be stable, secure, and reliable.  Because of the 
nature of the job, it is possible that we were sloppy somewhere and forgot 
to clean up a pointer.  Worse, we may go out of bounds, and overwrite 
valid memory.  Sometimes this can cause subtle problems, and it's hard to 
clearly see what's going on.  We have done our own internal testing to 
remove most of the common bugs, but there may be subtle ones that we 
missed.  To aid in checking for memory corruption, each debug call also 
calls malloc and free.  This severely hurts performance, but greatly 
assists the bug hunter.  To fully utilize this feature, it is helpful to 
export the environment variable MALLOC_CHECK_ to 1 or 2 before running.  
The unix manual page for GNU malloc has more information about this.  ('man
malloc')