MalCheck ======== Frequently Asked Questions -------------------------- == Q: What's a Magic Word? A: It's a fixed number, chosen at random, which is put at a certain memory location. If the value in that location is found to be different from the magic number at a later time, it means that the location was overwritten. MalCheck uses three different Magic Words: M1 at the start of the header, M2 at the end of the header, before the data, and M3 after the end of the data. == Q: Why is my call to MalCheck_setlevel() not reported in the output. A: The report for the call to MalCheck_setlevel() is of Action level. The default level is WARNING. This means that the first and maybe later calls to MalCheck_setlevel() is not reported. To force the call to be shown first set a light output level and then set to the level you want; the second call will be reported: MalCheck_setlevel(MalCheck_Action); /* Set light level */ MalCheck_setlevel(mylevel) /* This call is reported */ == Q: Why do I not get function names in the backtrace, but only ?() ? A: The backtrace uses function names which are normally embedded in the code by the compiler. You may have swithced it off with the -ff option for the compiler. Remove this option and use the -fn option for the compiler to switch it on explicitly. == Q: Why do I only get 20 levels of functions in the backtrace. A: MalCheck has only room to remember 20 functions, using an array of 20 pointers to the function names which are in the code. Luckily, the list starts at the youngest call, so the first one you will loose is _main(), which you don't need, and the next is main(), which you could guess. Apart from that: at those deep levels of nesting, neighbouring lines in the list of blocks might give an indication of what the older function names are. == Q: What CRC polynomal is used for the data and header CRC calculations? A: I don't know. I use the OS_CRC routine with stride 1. The PRMs give no details whatsoever. == Q: Why are all the names for this library preceded by MalCheck_ ? My fingers are getting tired from all that typing. A: This is to prevent clashes with names used in the program to be tested. The prefix MalCheck_ was chosen with the idea that no sane person would use such a name in a program. Tip: do not define your own names that start with MalCheck_... == Q: How can I call malloc() etc. in my program directly while using MalCheck? A: Surround the function name with parentesis, like this: (malloc)(123); == Q: How much work went into MalCheck? A: So far, about 50 hours. == Q: Why did you go through all the trouble to make MalCheck? A: My work on the port of GNU RCS to RISC OS was stuck on a particularly nasty bug which made the program crash under rather simple circumstances (no fancy options or anything). The system would be worst that useless with this bug it it. The problem was already holding up further development for 18 months. All I could say was that it crashed on a call to realloc(), so it probably involved a bad write to a dynamic area block. I got used to Dr. Smith's excellent MemCheck package to debug software I wrote myself for RISC OS. Unfortunately it needs to link with the Stubs Clib, while the RCS package can only be compiled with UnixLib. A friend I met at the RISC OS Expo 2002 (Leo Smiers, of !pdf and !Flash fame) suggested a simple setup by replacing malloc() etc with macros. This sounded like a good idea. Looking around on the Internet I found several packages to do exactly this, but they were either too simple, too complicated or not sufficiently documented. And I thought to myself: "How much work can it be?" As MalCheck was growing and getting fancier by the hour, the hot summer sun was making me break out in a sweat. At some point I actually had to use MemCheck to debug MalCheck. It turned out to be an "if(a=b) {}" silly error, which tought me to pay attention to compiler options and not simply copy Makefiles from other projects. Between the lines I also learned to use Makatic. After all this hard work, it payed off: I pinpointed the bug in just 15 minutes! There remained only a few minor tasks (8-<. Write a manual, polish the library and the header file, make a package, put it on the website... Just puting in the last final details in the library took a third of the total development time. The manual took up another third. == Q: Is Makatic still developed/supported? If yes, why is there no website? A: Actually, this is a question for you, the reader. If you know the answer, please tell me. == Q: What is this Id thing at the bottom of this file? A: That is an Identification string which gives some information about this version of the !Readme. The between the $-signs is automatically generated by the Revision Control System (RCS), for which I am developing the port to RISC OS, and a bug in which originally prompted me to create MalCheck. $Id$