Article # 1, added by Geoworks, historical record
| first |
previous |
index |
next |
last |
Swat "Death due to" and "Warning" message explanations
DS_SI_NOT_POINTING_TO_SPREADSHEET - ??? CANNOT_REMOTE_CALL_FROM_UI - cannot record a message from the system's UI thread. ILLEGAL_SEGMENT - One of the segment registers references a block that is no longer valid. Most likely, you have a pointer to a block that is no longer locked. Commonly this occurs when a message with a pointer parameter is sent with @send and the block that the pointer references is unlocked/freed before the sent message is handled. (Thus the pointer is invalid.) CANNOT_CALL_MEM_LOCK_ON_AN_OBJECT_BLOCK - This warning is caused by calling MemLock on an object resource (which is a specialized type of memory block). Note that this is a warning: it is up to you to decide whether the data being locked should be moved. This warning commonly occurs when one of your object's visMonikers is a gstring that references data via an optr (GR_DRAW_BITMAP_OPTR, GrDrawTextOptr, etc.) and that data is in the object resource rather than a data resource (which is read-only, lmem). The memory manager can more efficiently access the data if it is in a data resource rather than the (writeable) object resource. CANNOT_USE_DOUBLE_BYTE_CHARS_IN_THIS_VERSION - This error means an invalid character (something over FF hex) was passed to the routine (e.g., LocalUpcaseChar), but this verion of Geos doesn't support double byte characters. The problem may be that the character is being sign extended because the high bit of the byte is set. OBJ_DUPLICATE_BLOCK_NOT_DISCARDED - the resource to be duplicated is in memory. To fix this, add "discard-only" to the resource declaration in the .gp file. GRAPHICS_NO_FONT_FILES - occurs on startup if you don't have any files in your USERDATA/FONT directory. VIS_TEXT_RANGE_END_BEFORE_START - the value for the end parameter is smaller than the start parameter. For GEOS SDK 2.0, this is because the C header file has the parameters listed backwards. To fix this, simply swap the start and end parameters in the message call. TEXT_STRING_CONTAINS_NULL The string length in MSG_VIS_TEXT_REPLACE_ALL_PTR includes the null- terminator in the string or the string data is corrupted. If the string is null-terminated you may wish to pass zero as the string length. TEXT_PARA_ATTR_RUN_NOT_AT_PARAGRAPH_BOUNDARY - the death error occurs when a paragraph run element is not at a paragraph boundary. That is, the element's position is at a character other than a paragraph boundary. But I'm unsure why backspacing over a paragraph boundary would cause problems. The error-checking code should only be executed during editing operations or some other operation that causes the runs to be updated. If you have not already done so, do "ec text high" to get more error checking help. Also, use ptext just before you hit the backspace to see what the paragraph runs look like. LINE_DOES_NOT_EXIST - This error occurs when a message tries to get line information (VTI_lines) from a text object that hasn't been built out yet (the text object isn't visible on the screen). Make sure not to send messages like MSG_VIS_TEXT_CONVERT_OFFSET_TO_COORDINATE to a newly created text object until it is build out. VIS_TEXT_REACHED_LAST_REGION_WITHOUT_FINDING_NEEDED_COUNTS This is caused when the text object's internal data structures are getting is messed up and is not rippling data correctly. The ISV is somehow messing up the text object's internal data structures. TS_LOCK_TEXT_PTR_INVALID_RETURN_VALUE Your text object has gotten larger than 20K. It may be that the system only checks to see if a text object has gotten too large when the user is entering characters, that it doesn't in general do something graceful, leaving it up to the calling app. BAD_RELOCATION_CANNOT_FIND_VM_HANDLE - This can be cause by a library ldf or goh file being out of synch with the current library geode. Get new ldf and goh files. VM_GAP_EXISTS_IN_FILE - It could be caused by an improperly-created VM file created by something external to GEOS. Often, this is caused by a bug in the VM code itself. FSIR_NOT_LOCKED_SHARED_BY_THIS_THREAD - trashing your stack, or attempting to call FSDUnlockInfoShared when you've not called FSDLockInfoShared... CORRUPT_LINKAGE - the handle (or chunk handle) of an object is zero. The composite link is (therefore) corrupt. EVAL_ILLEGAL_PARSER_TOKEN - the parsed token is not one of ParserTokenType. ILLEGAL_RESOURCE - commonly caused by calling GeodeGetOptrNS in a single launchable app. MUST_SET_CONTEXT_BEFORE_SENDING_UNDO_MESSAGES ISV must set the context with MSG_GEN_PROCESS_UNDO_SET_CONTEXT VM_COMPRESS_HOSED we came to the last used block and found out that there are more blocks on the assigned list. LMEM_HEAP_SIZES_DONT_ADD_UP the size of all the chunks (as determined by LMValidateSizes) does not add up to LMBH_blockSize (size of memory block containing chunks). BAD_HEAP_SIZES The various heap/chunk sizes don't add up correctly. The offset to the heap start added to the sum of the chunk sizes doesn't match the value of blockSize (the stored size of the block). UNFREE_CHUNK_ON_LIST Somehow a non-free chunk is part of the free list. FREE_SPACE_WRONG The sum of the free-chunk sizes doesn't match the totalFree variable stored in the info. HANDLES_MATCH Two handles refer to the same chunk. HANDLE_OUT_OF_BOUNDS A reference to a handle which is outside the handle table has been made. ADDR_OUT_OF_BOUNDS A reference to a chunk which is outside the heap has been made. TAGS_DONT_MATCH The size/flags words at either end of a chunk do not match. CHUNK_WITHOUT_HANDLE A non-free chunk has been found which doesn't have a handle associated with it. HANDLE_TO_FREE A free chunk has been found that has a handle pointing at it. ADJACENT_FREE_CHUNKS Two adjacent chunks are marked as free. This is a no-no. They should have been coalesced. NOT_LMEM_HANDLE ECCheckLMemHandle* was called on a handle GRAPHICS_BAD_FONT_PATH Either there are no fonts in USERDATA\FONT, the standard path set for fonts is pointing off to oblivion, or the right file system driver isn't downloaded. This last will only happen in the non-EC, as error checking code in the EC will catch the case otherwise. NO_ONE_TO_SEND_SHUTDOWN_ACK_TO_ALAS Someone called SysShutdown(SST_CLEAN/SST_SUSPEND), passing cx==0, after the UI has exited, or before it started up. Memory errors: TOO_MANY_LOCKS A memory block may only have at most 254 locks placed on it, and you're on your 255th, or you're attempting to lock a fixed block. If the former, you're probably missing a MemUnlock for one of your MemLocks. If the latter, remember the tale of the person who told the doctor, "it hurts when I do this." BAD_UNLOCK You are attempting to unlock an unlocked block. CANNOT_CHANGE_OWNER You are attempting to change the owner of a non-sharable handle you do not own. Most likely, the handle whose ownership you think you're changing has long since been freed and re-used. HANDLE_SHARING_ERROR You are attempting to lock down a memory block owned by another geode that isn't marked HF_SHARABLE. Either you've got the wrong handle (e.g. you're using a handle for a block you freed, which was recycled by the system), or you need to mark this block HF_SHARABLE. ALLOC_ZERO You are not allowed to allocate a zero-sized block of memory. Allocate something HF_DISCARDED with a non-zero size if you just wish to reserve a memory handle for later use. MEM_FREE_BLOCK_DATA_NOT_CC This error is trigged when ec +heapFree is enabled and indicates that something has written outside the bounds of one of its blocks into unallocated memory. The system fills free blocks with 0xcc bytes and regularly checks all free memory to make certain all the bytes remain 0xcc. es:di-2 or es:di-1 is the first non-cc byte in the free block (the system checks for 0xcccc words, you see). What next? You should look at the data to see if they look like anything you might be creating (e.g. a recognizable text string), then look at blocks that fall just before the free block to see who allocated them and for what purpose, then take a look at the code that would be manipulating those blocks and see if they might scribble like this. ECF_UNLOCK_MOVE_FAILED_SORRY This indicates that the memory being moved because of ECF_UNLOCK_MOVE being set was swapped out and could not be swapped back in again, due to an error declared by the swap driver. MEM_REFERENCE_COUNT_NEVER_INITIALIZED MemIncRefCount was called on a block with a refCount of 0 - MemInitRefCount was never called on the block FAKE_BLOCK_DOESNT_COVER_ENTIRE_NEW_HEAP_SEGMENT A swap driver is attempting to extend the heap with a segment that must already part of the heap, as the block that intersects the start of segment being added doesn't cover the entire extent of the segment being added. OBJ_BAD_DEREF You called ObjDerefGen, ObjDeref1 or one of their friends but the master offset you are derefing does not have the master offset you are derefing. i.e. You are using the wrong deref routine. SOMETHING_LEFT_ON_STACK_BEFORE_STACK_SPACE_RETURN You called ThreadRestoreStackSpace with something left on the stack that you pushed after calling ThreadBorrowStackSpace. This is a bozo no no. THREAD_STACK_NOT_IN_LIST The list of thread stack blocks has been corrupted, possibly by someone calling HandleP on a geode's dgroup handle. TIMER_BAD_YEAR TimerSetDateAndTime() was passed a year outside the range (1980-2099) TIMER_BAD_MONTH TimerSetDateAndTime() was passed a month outside the range (1-12) TIMER_BAD_DAY TimerSetDateAndTime() was passed a day outside the range (1-31) TIMER_BAD_HOUR TimerSetDateAndTime() was passed an hour outside the range (0-23) TIMER_BAD_MINUTE TimerSetDateAndTime() was passed a minute outside the range (0-59) TIMER_BAD_SECOND TimerSetDateAndTime() was passed a second outside the range (0-59) TIMER_MISSED There's a bug in the timer code such that a timer with a time-remaining of 0 was placed on the timer list. This should not happen. It's not your fault :) LIBRARY_ENTRY_NUMBER_TOO_LARGE Calling ProcGetLibraryEntry with an exported-entry number larger than the number of entry points exported by the library (si holds requested number). UNKNOWN_HANDLE_TYPE_IN_HANDLE_TABLE FreeGeodeBlocks is running through the handle table and has hit a handle that is not one of the known non-memory handles. The handle table has been scribbled on. GRAPHICS_CANT_CREATE_ZERO_SIZED_BITMAP You can't pass zero width or height to GrCreateBitmap GRAPHICS_PATTERN_CUSTOM_PATTERN_TOO_BIG The custom pattern (either a HatchPattern or Bitmap) is too large to be used. A 16K limit is enforced for custom patterns, as these are stored in the GState segment. GRAPHICS_HATCH_PATTERN_DELTA_Y_CANT_BE_ZERO The HL_deltaY is defined to be in the rotated coordinate space of the hatch line (although the rotation may be zero), so it never makes sense to have a line that continually draws on top of itself. GRAPHICS_MUST_PASS_OD_TO_CREATE_BITMAP You must pass a non-zero exposure OD to GrCreateBitmap as the object that will handle any MSG_META_EXPOSED messages caused by bitblts and the like within the bitmap. GRAPHICS_BITMAP_ALREADY_COMPACTED GrCompactBitmap must be passed an uncompacted bitmap GRAPHICS_BITMAP_MUST_BE_PACKBITS GrUncompactBitmap must be passed a compacted bitmap in the PackBits format GRAPHICS_CANT_DO_THIS_WITH_COMPACTED_BITMAP Can't call GrClearBitmap or GrEditBitmap with a compacted bitmap. GRAPHICS_BITMAP_SHOULDNT_BE_LOCKED GRAPHICS_DEFINING_PATH_CANT_SET_DEFAULT_STATE You shouldn't be calling GrSetDefaultState while defining a path GRAPHICS_UNBALANCED_SAVE_RESTORE_STATE There is an unbalanced GrSaveState/RestoreState pair. Perhaps you are calling GrNewPage with saved states. GRAPHICS_ILLEGAL_PAGE_END_COMMAND GRAPHICS_ILLEGAL_PATH_TYPE GRAPHICS_BITMAP_RESOLUTION_CANT_BE_ZERO The bitmap resolution stored in the complex bitmap structure is zero, an invalid value. This may mean that the BMT_COMPLEX bit was set in the B_type field of the bitmap header when it shouldn't be. GRAPHICS_SENTINEL_FOR_BITMAP_COMPRESSION_CORRUPTED The sentinel word stored at the end of the buffer used to compress a bitmap has been corrupted, indicating an internal error in GrCompactBitmap GRAPHICS_BITMAP_COMPACTION_INTERNAL_ERROR GRAPHICS_BITMAP_INTERNAL_ERROR GRAPHICS_SENTINEL_FOR_BITMAP_BUFFER_CORRUPTED The sentinel word stored at the end of the buffer used for drawing complex bitmaps has been corrupted, indicating an internal error in either how the size of the buffer was calculated, or how someone is writing into the buffer. GRAPHICS_POLYLINE_SPECIAL_SHOULDNT_HAVE_FAILED A call to CheckThinLine() indicated a fat line would be drawn, but PolylineSpecial returned that a thin line would actually suffice. The logic to determine a thin line must be the same in each of these routines. Font Manager errors FONTMAN_FIND_OUTLINE_DATA_CALLED_WITH_BITMAP_FONT FontDrFindOutlineData() was called with a bitmap font. It is intended for use by font drivers, and therefore should only be called for fonts that have outline font data available. FONTMAN_BAD_ENUM_FLAG_PASSED_TO_IS_FONT_AVAIL GrCheckFontAvail() cannot alphabetize fonts. FONTMAN_BAD_FONT_INFO_FOR_ADD_FONT GrAddFont() was called with a bogus FontInfo() entry. FONTMAN_FONT_FILE_DELETED The font file was deleted between the time it was first used and the time the font manager attempted to reload a font from it. This probably indicates a bug in the font manager. FONTMAN_COULDNT_OPEN_FONT_FILE The font file couldn't be opened to reload a font from it. This probably indicates a bug in the font manager. FONTMAN_BAD_FONT_FILE_READ The file read of the font file failed. This probably indicates a trashed font file. FONTMAN_FONT_DRIVER_NOT_FOUND The font driver for this font couldn't be found. Is the driver specified in the geos.ini file? Is the (correct version of) the driver in the SYSTEM\FONT directory? FONTMAN_NEED_FEF_OUTLINES_OR_FEF_BITMAPS GrCheckFontAvail() and GrEnumFonts() need at least one of FEF_OUTLINES or FEF_BITMAPS set in the FontEnumFlags, otherwise no fonts will ever match. FONT_INIT_NO_POINTSIZE_FOUND No pointsize could be found for the default font. Something may be wrong with the file of the default font, such as a bad header. FONT_INIT_IN_USE_CHUNK_NOT_EMPTY The FontsInUse chunk was not empty during initialization. Something is probably wrong in GrInitDefaultFont() or GrInitFonts(). FONT_BAD_WEIGHT You should not use FontWeights in the range FW_ULTRA_LIGHT to FW_BLACK. These are provided for backwards compatibility only. FONTMAN_FILE_CACHE_CORRUPTED The font file cache was somehow corrupted (eg. a font in the cache didn't exist, was listed in the cache twice, etc.) WIN_INPUT_OBJ_MUST_BE_RUN_BY_SAME_THREAD_AS_GEODE_INPUT_OBJ This is an error that WinOpen generates if the passed "InputOD" & "owner" for geode are not compatible. Any non-NULL InputOD passed must be run by the same thread as runs the owner-to-be's geode's input object, by default the geode's GenApplication object. This is necessary not because of a kernel requirement, but because GenApplication expects to be able to call any InputOD of a window that it has received input for. WIN_ERROR_MOVING_WINDOW_ALREADY_IN_BACK_TO_BACK A window or window layer, after being moved to the back, was found to have no siblings to its/their right before beingmoved. Code earlier in the routine is supposed to have bailed out in this case with nothing to do. WIN_BAD_ASSUMPTION Bad assumption internal to window system code OBJ_FLUSH_INPUT_QUEUE_BAD_NEXT_STOP Result of default MetaClass handler for MSG_META_OBJ_FLUSH_INPUT_QUEUE being called with bogus ObjFlushInputQueueNextStop value OBJ_ILLEGAL_REFERENCE_TO_DYING_OBJECT_BLOCK Object block being tested has had MSG_META_BLOCK_FREE or ObjFreeObjBlock called on, is no longer marked as "in use", & will be nuked from memory the moment the queues have finished being flushed. The current operation being performed requires this NOT to be the case. One example is "WinClose", which requires that the exposureObj & inputObj's not already be dying. This can be corrected by first closing the window, or changing its inputObj or exposureObj to NULL, & THEN destroying the object, or object block. More in-depth info: This error checking routine is called by the system when it is about to start another queue-flushing sequence to an object, to make sure that it's going to be around to be able to receive the message -- if the block's about to be freed within one queue flush, then the new flush doesn't stand any chance of being able to finish without crashing. OWNER_CORE_BLOCK_NOT_LOCKED The kernel is unrelocating a handle and has found that the core block for the owner of the block being unrelocated is not, in fact, locked. VM_FILE_MUST_BE_CLOSED_WITH_VM_CLOSE A geode tried to close a VM file by calling FileClose instead of VMClose. This often happens if a geode has a VM file open, and exits without closing it. ATTEMPTED_TO_PERFORM_UNSUPPORTED_FUNCTION_BEFORE_APPROPRIATE_IFS_DRIVER_WAS_LOADED The proper file system driver for one of your PC's drives didn't get loaded. Since the system::fs key in the INI file was not set, Geos polled the system to determine what drives are present and didn't recognize the response it received. To fix this problem: If you're using MS-DOS 7 (Windows 95) or PC-DOS 7, add the following line to the [system] category of the GEOS.INI file. fs = ms4.geo This will force the appropriate file system driver to be loaded. (For EC emulator, add "fs = ms4ec.geo" to the GEOSEC.INI file.) If you plan on reinstalling the target software and don't want to always have to update the INI file, you can do the following as a more permanent solution: For MS-DOS 7, you'll need to enter these three lines at the DOS prompt, then reboot the machine: CD\WINDOWS SETVER LOADER.EXE 6.3 SETVER LOADEREC.EXE 6.3 If you're using PC DOS 7, you'll need to make sure that this line is in your config.sys file: DEVICE=C:\DOS\SETVER.EXE then reboot your machine and enter this line at the DOS prompt: SETVER LOADER.EXE 6.3 SETVER LOADEREC.EXE 6.3 then reboot your machine again. INVALID_FSDRIVER_OFFSET Called FSDUnregister with an offset that's not a registered FS driver, as returned by FSDRegister. FSIR_MAY_NOT_BE_LOCKED FileGetDestinationDisk has been called with the FSInfoResource locked in some way. This can lead to deadlock, however, when the disk for a drive specifier is registered. FSHOF_SET_FILE_NAME_PASSED_TO_SKELETON_DRIVER The skeleton filesystem driver has been told the name of a file opened before the other drivers were loaded. This means the file in question was opened on a drive for which the driver was not loaded. Likely you will die soon of some other error. VM_READ_FILE_WORD_ERROR A call to VMFileReadWord() returned an error. Given that this is simply doing a file pos, and then reading from a portion of the VM header which is assumed to exist, an error is a bad thing. See Tony. VM_ATTACH_BLOCK_CANNOT_BE_DETACHABLE A block that is passed to VMAttach must be NOT_DETACHABLE, so as to avoid confusing the application state file mechanism, which will expect to be able to save the block to the state file when the application is detached. The NOT_DETACHABLE attribute can be set in a .ui file with "start Resource, notDetachable" or in a .goc file with "@start Resource, notDetachable;" VMEM_GENERIC_OBJECTS_CANNOT_BE_UPDATED_ASYNCHRONOUSLY The file whose handle is in BX has VMA_COMPACT_OBJ_BLOCK set without having VMA_SYNC_UPDATE set. This is illegal, as it implies that whenever a block containing generic objects is off-screen, it can be compacted, thereby losing all non-save-to-state vardata and other things that could well be vital to bringing the objects back on-screen. CANNOT_TRUNCATE_MULTI_REFERENCED_VM_FILE Someone has called VMTruncateAndClose for a VM file that has been opened by more than one application. Since VMTruncateAndClose is an extremely destructive operation, rendering the VM file invalid, the kernel refuses to perform it unless it knows only one process is using the file. DB_UNGROUP_NOT_LOCKED VMMarkUngroupAvail has been called passing the handle of a group block that's not locked. This is illegal, as the handle for the block could go away at any time... this is an internal error in the kernel DB code. UNGROUPED_GROUP_MAY_NOT_BE_PASSED_AS_AN_EXPLICIT_GROUP DBAlloc was called passing a group in AX that is a member of the set of groups used to satisfy requests for DB_UNGROUPED allocations. For various reasons, this is against the rules. Use DB_UNGROUPED instead, or create your own group (if you need to have items end up in the same group, for some reason). ***** OBJECT ERRORS ***** BAD_REMOVE_CHILD BAD_CLASS This error happens frequently when an object or object block is freed before a message in the queue destined for it is delivered. Always use as high a level of object/block destruction mechanism as you can -- The highest object-level routine in the UI is MSG_GEN_DETROY, in vis, MSG_VIS_DESTROY. Lower is MSG_META_OBJ_FREE, which first flushes queues after which a MSG_META_FINAL_OBJ_FREE is sent to the object. The handlers for this last message are allowed to use ObjFreeChunk & LMemFree. On the block side, once all objects within the block have been taken out of any tree they resided in, MSG_META_BLOCK_FREE & ObjFreeObjBlock are the high- level message/routine to use. MSG_META_FINAL_BLOCK_FREE ends up being called only after the queues have been flushed out, which in turn is allowed to actually nuke the block. LMEM_BAD_INSERT_OFFSET LMemInsertAt() was passed a bad offset. The offset passed should be the offset from the start of the chunk you are inserting in. LMEM_BAD_DELETE_OFFSET LMemDeleteAt() was passed a bad offset. The offset passed should be the offset from the start of the chunk you are deleting in. LMEM_BAD_DELETE_SIZE LMemDeleteAt() was passed a bad size. The passed size to delete was larger than the existing chunk. LMEM_BAD_DELETE_COMBINATION LMemDeleteAt() was passed a bad offset/size comibination. The offset plus the size extends beyond the end of the chunk. OBJ_BLOCK_BAD_IN_USE_COUNT Each object block contains an "in-use" count, which is stored in the ObjLMemBlockHeader (The field is OLMBH_inUseCount). The count starts out as 0, indicating objects are not active, climbs during usage, & must return to 0 before the block may be destroyed. If you've gotten this error, it is because the count went negative, or became far to large to be a reasonable value. The most common cause of this is intercepting & not passing on to the superclass a method which inc/decs this count. So, which methods might these be? The count is incremented each time an object becomes active in some new way in the system, & is decremented each time an object is no longer active in that way. Currently, there are the following pairs: 1) Incremented whenever a window is created for visible objects having the VTF_IS_WINDOW bit, & decremented in the default handler for MSG_META_WIN_DEAD. 2) Inc in MSG_META_OBJ_FREE (sent when objects are being destroyed)/ Dec in MSG_META_FINAL_OBJ_FREE (sent out after queues interacting with object have been cleared) 3) New object classes are free to inc/dec this count as well, using ObjIncInUseCount & ObjDecInUseCount, but must do so in pairs, or this fatal error may be the result. Also -- note that if a decrement does not occur for each increment, then the count never reaches zero, resulting in the block never getting free/ application never exiting. OBJ_BAD_IN_USE_COUNT Indicates if in-use count has gone negative for this particular object (The EC code only keeps track of the in-use count on a per-object basis). See above OBJ_BLOCK_BAD_IN_USE_COUNT for more info. OBJ_BLOCK_BAD_INTERACTIBLE_COUNT Each object block contains an "interactible" count, which is stored in the ObjLMemBlockHeader (The field is OLMBH_interactibleCount). The count starts out as 0, & becomes non-zero as objects in the block become visible, or need to have current status information reflected in their state. GenControl objects are not updated unless this value is non-zero. This error occurs only if the value goes negative, which should never happen, as the count should only be changed by in/dec pairs. So, which methods might these be? Currently, there are the following pairs: 1) Incremented whenever a window is created for visible objects having the VTF_IS_WINDOW bit, & decremented in the default handler for MSG_META_WIN_DEAD. OBJ_BAD_INTERACTIBLE_COUNT Indicates if interactible count has gone negative for this particular object (The EC code only keeps track of the interactible count on a per-object basis). See above OBJ_BLOCK_BAD_INTERACTIBLE_COUNT for more info. OBJ_RELOCATION_TO_INVALID_LIBRARY_NUMBER The application is probably restoring from state and one of its libraries, or its libraries' libraries exports an object class an instance of which was saved to state, but now one of the libraries or libraries' libraries has changed what libraries it imports without having increased the protocol number, so the state file is invalid. RELOCATION_TO_INVALID_LIBRARY_ROUTINE_NUMBER This can happen if you're using a library whose entry points in the .gp do not match the one your geode was compiled with (because it's too old, etc). BAD_TABLE_SIZE_PASSED_TO_OBJ_VAR_SCAN_DATA The # of VarDataHandlers passed to ObjVarScanData is unreasonable (0, or very large) BAD_SIZE_PASSED_TO_OBJ_VAR_ADD_DATA Size of extra data passed to ObjVarAddData is unreasonably large CLASS_AT_DS_SI_MARKED_NEVER_SAVED_SO_WHY_AM_I_RELOCATING_OR_UNRELOCATING_IT_BUB? This death occurs if a class has been @classdecl'ed with the "neverSaved" flag but an object of that class is being saved to state. To fix the problem, either mark the object "ignoreDirty" (so it doesn't save to state) or remove the "neverSaved" flag from the class declaration. Note that GenProcessClass subclasses should be marked neverSaved because process objects don't have any instance data thus they are never saved to state. OBJ_SHUTDOWN_OR_DETACH_WHILE_OTHER_STILL_ACTIVE ObjInitDetach was called for an object while a previous MSG_META_DETACH or MSG_META_APP_SHUTDOWN was still active for the object, and the message passed to ObjInitDetach is different from when ObjInitDetach was first called for the object (e.g. a MSG_META_APP_SHUTDOWN was received before the object sent MSG_META_ACK back to the object that sent it a MSG_META_DETACH). You might also have trashed AX before calling ObjInitDetach, so it didn't receive the message number your object actually received. FSD_LOADED_BUT_NOT_REGISTERED When restoring a disk handle, was able to find the core block for the IFS driver, but not its FSDriver record. Likely the FSDriver chain has been corrupted. SAVED_DISK_HAS_NO_DRIVE_SPECIFIER_FOR_DRIVE_NAME When trying to locate the drive for a saved disk handle, we were told the saved drive name, which should always be a name followed by a colon (aka a drive specifier), had no drive specifier. Either DiskSave screwed up or, more likely, the saved data have been corrupted by the application. DRIVE_NOT_LOCKED_EXCLUSIVE You are attempting to release exclusive access on a drive that is marked as being locked for shared access. INK_ENUM_EXCEEDED_END_OF_BUFFER We tried to terminate a line segment, but there were no points in the point buffer. NUM_INK_POINTS_IS_ZERO We are sending ink off, and the # points is 0. This shouldn't happen. INK_Y_COORD_IS_NEGATIVE Somehow, an ink point had a negative Y coord CANNOT_DELETE_MORE_POINTS_THAN_EXIST For some strange reason, the code tried to delete more points from the input manager ink buffer than actually existed. TOO_MANY_INK_POINTS INK_DATA_EXCEEDED_BOUNDS_OF_BUFFER More ink points have been stored in the ink buffer than should be able to fit. NO_INK_GSTATE MSG_IM_INK_REPLY was received but there was no inkGState for some reason One of the handlers for the ink collection finite state machine trashed AL... Indicates that the MSG_IM_INK_REPLY (with AX=TRUE) was received before any pointer window was set IM_ERROR_BAD_PTR_IMAGE_VALUE Indicates that ImSetPtrImage was called with cx = 0, but dx was not set to a legal PtrImageValue. IM_MEMLOCK_FAILURE Internal IM problem IM_BAD_SETPTR_PARAMS Internal IM problem IM_MONITOR_ALREADY_IN_MONITOR_CHAIN You have attempted to call ImAddMonitor passing a Monitor structure that is already in the monitor chain. You need to have called ImRemoveMonitor on the Monitor before you can add it back in again GCN_BAD_USAGE_COUNT Result of NDBH_usageCount within a NotificationDataBlock having an abnormally large number in it. You passed both GCNLSF_RETURN_COUNT and GCNLSF_SET_STATUS to GCNListSend or GCNListSendToBlock, but the two are mutually exclusive, as the undisturbed status message handle is expected to be returned in cx. GCN_UNRELOCATING_GCN_LIST_WITH_UNOWNED_OPTR Cannot unrelocate a GCN list with optrs that are owned by someone other than the owner of the GCN list itself. FSD_ES_ISNT_SHARED_FSIR A routine was expecting FSInfoResource to have been locked shared and its segment loaded into ES. OVS_BAD_HANDLER_TABLE The pointer passed to ObjVarScanData does not point to a valid VarDataHandlerTable or VarDataCHandlerTable. OVS_SIZE_OF_VAR_DATA_ENTRIES_GREATER_THAN_VAR_DATA_AREA The variable data storage area of the object has been corrupted -- the sum of the sizes of the individual entries exceeds the total size of the variable data storage area. One common cause of this is that a class definition in a library uih/goh file at the time the app was compiled no longer matches the structure of the class in the library found at runtime. This can happen if instance data was added to a library class, but the major protocol of the library wasn't increased (e.g., you're using an new SDK, but an old application). OVS_CORRUPTED_VAR_DATA_ENTRY The VDE_entrySize field was 0, which is illegal. This field must be at least (size VDE_entrySize + size VDE_dataType). OVS_VAR_DATA_HANDLER_CHANGED_DATA_ENTRY A VarDataHandler or VarDataCHandler has changed the data entry it is handling. This is illegal. A VarDataHandler or VarDataCHandler is not allowed to change the data entry or add or remove data entries. A data entry size of 0 or 2 was passed to ObjVarAddDataEntry. ObjVarAddDataEntry is only used to add a data type with extra data. If a data type with no extra data is to be added, use ObjVarAddDataType. OVS_BAD_MSG_META_INITIALIZE_VAR_DATA_HANDLER MSG_META_INITIALIZE_VAR_DATA has been called on an object to get a particular variable data type created & initialized, and ds:ax has NOT been returned, as is required, pointing to the extra data of the new data entry (Should match return value of ObjVarFindData for the given data type) OVS_VAR_DATA_HANDLER_ADDED_OR_REMOVED_DATA_ENTRY After calling a VarDataHandler or VarDataCHandler, the size of the vardata area for the object has changed. It is not allowed for a handler to do anything which can cause this to happen, such as add or remove vardata entries to/from the current object. For this reason, it is also not advisable to make any message calls from within a handler, unless it is known that no current or future handlers for that message would be adding/ removing vardata entries to/from this object. BAD_DETACH_MSG ObjInitDetach was called with AX != MSG_META_DETACH or MSG_META_APP_SHUTDOWN TIMER_NOT_STOPPED_BEFORE_GEODE_EXITED A timer for the currently-exiting geode (ds:bx.HM_owner is the handle of the geode) remains on the timer list. All timers belonging to a geode