Some Important Notes On Specific Crashes And Crashing Conditions ================================================================ Hard/Software Conflicts ~~~~~~~~~~~~~~~~~~~~~~~ IDE-MaxTransfer Problem ----------------------- Since superview.library usually holds very large buffers within memory, it also likes to read and write these completely from and to disk. This means, that the specific device drivers are confronted with quite large values of bytes to be read or written, which perhaps usually does not happen very often. Sometimes the firmware of IDE-Harddrives, like used with the A4000/030-040 or A1200HD, does not support transfers of blocks larger than 64K (65535 Bytes) during one single write operation. Ususally the DOS splits larger writing calls to take care of this restriction. But since this is just a lack of performance and actually does not comply to the IDE/AT standard, the default value for this "MaxTransfer" is not 0xFFFF (64K) but 0xFFFFFF or 0xFFFFFFFF instead. If any written graphics files are mysteriously damaged or will be read incorrectly (writing is more critical than reading), you should start your "HDToolBox" and select "Partition Drive" for the concerned HardDrive. After that activate "Advanced Options" and chose "Change". Modify the "MaxTransfer" field, so that it does reflect "0xFFFF" then. After that leave all the windows by confirming "OK" and select "Save Changes to Drive" (no longer disabled) on the first window. >>> Do not change any other settings within "Partition Drive", if you don't know, what you're doing, since actually partitioning your HardDisk would cause your complete data to be lost. If you'd changed something you didn't want to change, just "Cancel" and start from the beginning <<< Perhaps you'd like to know, why I did mention this here ?! Well, some weeks after I bought a new M*xt*r 540 MB HD, superview.library did seem to have x-time more bugs than before, which almost all could not be explained rationally: writing a "clean" buffer to disk in several file formats (did not matter), with this buffer still beeing valid after the write operation, resulted in damaged graphics after loading. If uncompressed, the data still was all there, but like a kind of mosaic, with always some blocks at the wrong places... It took me some weeks to actually realize the bug itself and approximately two days to find out, *why* it happened... %-( Crashes caused by other Programs ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Here's an alphabetical list of programs, which either cause superview.library to crash, or which do crash relatively often and unexpected (so that it might seem, as if superview.library crashed): - AutoCLI V2.xx © by Nic Wilson Problem: AutoCLI sometimes might crash, when there's no appropriate window available when e.g. trying to open a shell via Hotkey. Solution: (don't use the hotkey feature) - EGS libraries V6 and V7 © VIONA Development Problem: When flushing the EGS libraries (at least after using the Amiga emulation mode), it seems that the libraries will cause recoverable alerts with OS 3.x. Maybe on some systems crashes will occur. Don't know, whether the libraries are really the source, but it's likely. Solution: (don't flush) - NewMode V3.3 (and below) © 1992-95 by Andreas Linnemann Problem: Has been reported to cause serious problems when running together with e.g. SuperView (when attaching a fixed ViewMode to the program). Solution: (Already fixed for newer versions. I, personally, would strongly recommend not to promote any SuperView Screens via NewMode, since now for almost any configuration there should be suitable SVDrivers - alternatively also a RTG-configuration for AGA.svdriver) - SnoopDos 3.00 © Eddy Carrol, September 1994 Problem: When monitoring OpenLibrary() calls with SnoopDos 3.0, while loading the libraries into RAM, ramlib will _sure_ crash with an "...3 odd address" guru when loading one of the SVObjects. This does not happen when the libraries have already been loaded into RAM before and does also not happen with older SnoopDos releases. Can't say, whether this is a problem of SnoopDos, ramlib or the library, but maybe it has s.th. to do with trashed A0/A1, pointers badly corrupted under different circumstances. Solution: Deactivate "OpenLibrary" under "Functions" and save the preferences. You will still be able to see, which libraries are loaded (LoadSeg), but can't detect any version numbers (use an older SnoopDos like e.g. V1.7 for this). - SuperDark 1.5c,V2.1a © by Thomas Landspurg Problem: Some of the Screen Blanker modules will crash on AGA OS3.x systems. Solution: Find out, which of them do so (e.g. ASwarm, as far as I know) and deactivate them ! - VMM Problem: Someone told me, that VMM caused SuperView(-Library) crashing because of Enforcer Hits, which did not happen without it. Well, consider this facts: superview.library usually does allocate all memory with the MEMF_PUBLIC flag set. This memory will not be "virtualized" by VMM because there's a common agreement - not respected by many programs - that this is memory which has to be in RAM always. This default behaviour may be overriden by setting special settings within VMM, e.g. setting 10240 for both - MEMF_PUBLIC as well set or cleared - within "advanced options". By doing so, VMM might be caused to not only virtualize large graphics buffers, but maybe also Messages, IORequests and other things. This simply may cause crashes. Solution: (If it does not work, don't use it with SuperView - I've been told that the above method works without problems, but you try it at your own risk - maybe the library's behaviour will change in the future. Either better using the MEMF_PUBLIC flag or crashing by beeing badly virtualized ;-( Conditional Configuration Crashes (CCC ;-) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Some very special configurations (which occur when people do configure their programs wrong, or installation programs do weird things) may cause the whole system to crash. If you know more about such crashing conditions, please report it to me. -- Andy, 9.10.95