Blowup -- Catches and displays task errors Written by Olaf `Olsen' Barthel Public Domain ------------------------------------------------------------------------------ 1. What is it? Blowup catches tasks, processes and programs trapped in exceptional error conditions. Such conditions include attempts to execute unimplemented CPU instructions, trying to divide a number by zero, to access data/instructions located at invalid addresses and many others. This is also what the operating system does, but Blowup adds to this by providing additional information on the cause of the error. Also, Blowup will attempt to safely catch errors caused by tasks; the operating system does not do this: once a plain Task is trapped in exceptional error conditions, the exec kernal will trigger a dead-end alert and reboot the machine. Blowup is a quality assurance tool which in the right hands can be used to detect and remove errors in Amiga software. Blowup works best if used together with tools like Enforcer, SegTracker, Memoration, Scratch and Wipeout (the first four are all part of the Software Toolkit, as distributed in the 3.1 Native Developer Kit or on the Amiga Developer CD v1.1). Blowup does not work with the "tnt" program; it is meant to be an alternative to tnt. Blowup is related to the tnt and GOMF tools, but unlike these offers more and different functionality. It is definitely not a replacement for the Enforcer tool; all it can do is complement its functionality. But then, if your Amiga has no MMU, Blowup and Wipeout provide functionality similar to Enforcer; this is as close as it could get. 2. Requirements Blowup requires an Amiga equipped with Kickstart 2.04 or better. Aside from the operating system version, there are no special requirements. Since Blowup sends its output to the built-in Amiga serial port or the parallel port, you should either have a terminal or a printer connected to your machine, or you should run a program like Sashimi or Sushi to capture its output. 3. What Blowup does Blowup installs custom trap handlers for every task, process and program currently running and also patches the exec kernal AddTask() routine to the effect that every new task added will also have the custom trap handler installed. This custom trap handler will be invoked every time the corresponding task is trapped in an exceptional error condition. When this happens, Blowout will output information on the task, the location of the error and bring up an error requester prompting you to choose whether the task that triggered the error should be suspended until the system is rebooted or whether you want to reboot the system immediately. 4. Interaction with other programs Blowup should be smart enough not to interfere with trap based debuggers, such as the SAS/C CodeProbe debugger. It will install the custom trap handler only if the task to be modified does not already have a custom trap handler installed. 5. Command line options Blowup can be started only from Shell. If it is started for the first time, it will patch the exec kernal and modify all currently running tasks, processes and programs to use the custom trap handler. I recommend to always run Blowup in the background, like this: run >nil: Blowup Every other attempt to start Blowup will only cause the running Blowup configuration to be updated. The following command line options are available: OFF This turns off an already running Blowup. PARALLEL This option activates parallel port output; default is serial port output through kprintf(). NOBANNER This option will cause Blowup not to print its banner message when it is started. AREGCHECK These options tell Blowup that you wish all the values NOAREGCHECK in the address registers to be checked via SegTracker; default is NOAREGCHECK. DREGCHECK These options tell Blowup that you wish all the values NODREGCHECK in the data registers to be checked via SegTracker; default is NODREGCHECK. STACKCHECK These options tell Blowup that you wish all the values NOSTACKCHECK displayed in the stack to be checked against the global segment lists via SegTracker. This will tell you in what segment lists various return addresses on the stack are found, which may help in tracing the location of an offending command. Default is NOSTACKCHECK. STACKLINES=number This option lets you pick the number of lines of stack backtrace to display. The default is 2. If set to 0, no stack backtrace will be displayed. There is NO ENFORCED LIMIT on the number of lines. 7. Signals Blowup watches for one signal that can be sent to it either by holding down the [Ctrl]-C keys or through the Shell "Break" command: [Ctrl]-C Turns off Blowup 8. What is in a Blowup report? Here is a sample Blowup report with a few annotations: TASK TRAPPED 1) 18-Apr-98 12:46:06 2) Address error 3) TRAP=0x03 SR=0x0000 PC=0x084A1416 TCB=0x08571F20 4) PC: 4EB90000 00014E75 31323334 35363738 0000084A 1DC80000 00300212 850E0000 5) Data: 00000000 00000001 00000002 00000003 00000004 00000005 00000006 00000007 6) Addr: 00000010 00000011 084A1416 0869075C 00000014 00000015 00000016 0869075C 7) Stck: CACACACA 0819F59C 00004E20 08572944 00000000 086B8E90 000039D8 2053746F Stck: 7054696D 65722856 4F494429 3B0A564F 49442053 74617274 54696D65 7228554C 8) Name: "Background_WShell" CLI: "crash3" "crash3" Hunk 0000 Offset 00000046 1) This is the time and date of the Blowup hit, i.e. the point of time when an error condition was triggered. 2) This indicates what type of problem occured; in this case an address error has occured. 3) This line shows the error type ("TRAP=0x03") which corresponds to the description in 2), the contents of the status register ("SR=0x0000"), the address of the program counter ("PC=0x084A1416") and the address of the task that triggered the error condition ("TCB=0x08571F20"). The program counter refers to the location of the error; in some cases it points to the instruction that caused the error, in some it points behind it. For more information, see the CPU User's Manual (such as the "MC68040 User's Manual" available from Motorola). The status register is of particular interest. In the case shown above it reads 0x0000 which among other things tells that the error occured while a program was executing in user mode. The status register consists of two bytes, with the upper being the system byte and the lower the user byte. If the system byte is non-zero, Blowout will never show a requester to prompt you what to do next, it will always drop into a dead-end alert. 4) These are the first few long words located around the program counter address listed under 3); they show you the command to be executed when the error condition was triggered. 5) This is a dump of the MC68000 data registers 6) This is a dump of the MC68000 address registers 7) This is a dump of the stack active at the time the error condition was triggered. 8) This is the name of the task and the program name that triggered the error condition; first the task name, then the CLI program name and the location of the call in that program. In some cases, the CLI program name may be omitted or the hunk/offset information may not be available. 9. How useful is a Blowup report? While Blowup performs a service which Enforcer cannot, it is by no means a replacement for Enforcer. Blowup is particularly useful when tracking down comparatively "harmless" errors like a division by zero or an attempt to execute an unimplemented instruction (e.g. caused by trying to execute a program on a plain 68k machine which was compiled for use on 68020 machines). As for the rest, it might still prove useful, but due to the nature of the errors it traps, the reason for the error might not be directly related to the error the CPU has detected. For example, trying to access uninitialized memory can cause the CPU to keep following further unitialized memory references, eventually resulting in an illegal instruction error or an address error. Trying to trace back the cause based upon the symptom may thus prove impossible; who knows, maybe the error occured due to which random patterns memory was initialized at the time of the crash -- which may not be reproduceable. In those cases, Enforcer scores much higher as it will detect illegal memory accesses as soon as they occur, and not just when the CPU has hit a dead end. Concluding, Blowup may help to provide the key to solving a software problem, it is unlikely that it provides sufficient information to solve it all on its own. Therefore, always run Blowup with Enforcer, SegTracker and possibly Wipeout. 10. Source code For your convenience, the complete program source code is included in the distribution. Should you find bugs, make updates or enhancements, feel free to contact me. The source code was written for the SAS/C compiler. 11. Author information If you wish to contact me about Blowup, you can use the following postal address: Olaf Barthel Brabeckstrasse 35 D-30559 Hannover Federal Republic of Germany or you can use this e-mail address: olsen@sourcery.han.de 12. Release history Blowup 1.3 (18.4.98) - Initial public release