readme.bc

DOS环境下C/C++语言内存问题检测 numega的产品

      28. "The Only Nu-Mega Driver Supported etc." MESSAGE
      -------------------------------------------------------------------
	 This message usually means the	user was trying	to run BOUNDS-
      CHECKER for DOS in a Windows DOS box. BOUNDS-CHECKER uses	some
      protected-mode features to detect	program	errors,	so it cannot 
      co-exist with other protected-mode programs. A DOS box under
      Windows is a Virtual Machine, which is a protected-mode emulation
      of real-mode DOS operations.
      
      -------------------------------------------------------------------
      29. BOUNDS-CHECKING SPAWNED PROGRAMS
      -------------------------------------------------------------------
	 The correct way to Bounds-Check a spawned program is to spawn a 
      Bounds-Check of that program. BOUNDS-CHECKER will	not follow a	 
      spawn into a child program. The parent and child programs	must be	 
      Bounds-Checked separately.
      
      -------------------------------------------------------------------
      30. SUMMARY OF COMMON ERROR MESSAGES AND WHAT TO DO
      -------------------------------------------------------------------
	 Common	Error messages displayed by BOUNDS-CHECKER and what they 
      mean:
	  *********************************************************
		       Write to	Location xxxx:xxxx
		       Read from Location xxxx:xxxx
	  *********************************************************
      Description:  Out-of-bounds reads	and writes cause this message.	
      The name of the area that	is being accessed is printed beside the	
      message.	If the address that you	are writing to is in your code 
      area, then the message "This is an Overwrite to your code area" 
      will be printed after the	"Write to Location" message.

      Probable Cause:  - You are using an uninitialized	pointer

      Recommended Action:  Examine the highlighted code	line and check 
	all pointers to	determine whether they were initialized. Some of 
	these accesses may be legal.  Use /SMART mode to help determine	
	whether	it is indeed a legal access.

	If you are sure	that this is a legal access, ADD it to the 
	exception file.


	  *********************************************************
		     Error, Source Will	Overrun	Destination
	  *********************************************************

      Description:  This error indicates that a	string write library 
	routine	is about to overrun the	boundary of a data object.  
	ROUTINE.DAT contains a list of the library routines watched by
	BOUNDS-CHECKER.

      Probable Causes:
	- Passing a string that	is not NULL terminated
	- Passing a source string that is too long for the destination
	- Passing an incorrect length parameter

      Recommended Action:  Use the Data-Info option to find what the
	lengths	of the source and destination variables	are.  If you 
	continue on, any data immediately after	the destination	buffer 
	will be	overwritten.  The consequences vary, but usually will 
	cause a	blowup later in	the program. You should	exit, fix the 
	problem, and then BOUNDS-CHECK your program again.


	  *********************************************************
			   Owner is Free Block
	  *********************************************************

      Description:   Your program is accessing a block of memory that has
	not been allocated to any program.

      Probable Causes:
	- A stack overflow has occurred.  To check this, select	O for
	Options	and A for Assembler. If	the value in the SP register is
	is low (i.e. 0002) or very high	( i.e. Fxxx ), then the	cause is
	a stack	wrap-around. This is a common problem with Borland-
	compiled programs because their	default	options	do not include
	stack-overflow checking. NOTE: many third-party	libraries do not
	contain	stack-checking code, so	you may	get stack overflow even	
	when stack-checking is included	in your	compile	options.
	- You have two pointers	pointing to the	same block of memory and
	you have freed one but are still trying	to use the other. Since
	you already freed the block, it	no longer belongs to your 
	program.
	- You are using	an uninitialized pointer, which	contains an 
	address	that is	outside	your program space.

      Recommended Action:  In the case of stack	overflow, increase your
	stack size. Otherwise, verify that all pointers	used within the
	source line have been initialized and are not pointing to freed	
	blocks.

	  *********************************************************
		 Write to Location 0000:0001 ( or 0000:xxxx )
	  *********************************************************

      Description:  Location 0000:0001 is an address within the	interrupt
	vector table. These addresses are all word values, so any odd-
	numbered address (which	is a byte within the word) indicates an
	error. When BOUNDS-CHECKER traps a free, it places the address 
	0000:0001 into the pointer.  If	that pointer is	used again, then 
	the message above will be displayed.  If the referenced	address	
	is 0000:0001, probably this is a freed pointer being used again.
	If it is some other address beginning with 0000:, your program
	is addressing the interrupt vector area, and you should	check 
	whether	that is	legitimate for the source being	displayed.

      Probable Cause:
	- You are trying to use	a pointer that has been	freed.
	- You are trying to use	a pointer that is uninitialized.

      Recommended Action:  Check the pointer to	determine whether it has 
	been freed.  If	the pointer has	not been freed,	then verify 
	whether	it has been initialized	- an uninitialized pointer will
	contain	0000:0000.


	  *********************************************************
		      Error, Bad Address Passed	to Free
		     Error, Bad	Address	Passed to ReAlloc
		   Free	Has Been Called	with A Bad Address
		 Realloc Has Been Called with a	Bad Address
	  *********************************************************

      Description:  These errors indicate that you are trying to free or 
	reallocate an allocation pointer which does not	point to a 
	legitimate allocated memory block.  The	actual address being 
	passed is displayed with the message.
	The allocation-free libraries do not check the validity	of the
	addresses passed to them, but they write to internal structures
	based on those addresses. A call to free a bad address may cause
	overwriting of valid data, and will almost certainly corrupt the
	heap.

      Probable Causes: 
	- Freeing or reallocating a pointer that was never allocated.
	- Freeing or reallocating a pointer that was already freed.
	- Freeing or reallocating a pointer containing an address that
	could not possibly be an allocated block ( i.e low memory ).

      Recommended Action:  Continuing at this point will usually cause 
	heap corruption, so it is best to exit,	fix the	problem	and 
	BOUNDS-CHECK your program again.


	  *********************************************************
		 Error,	Overrun	has occurred in	Allocated Area
	   An Overrun of an allocated block of Memory has been found
	  *********************************************************

      Description: When	BOUNDS-CHECKER traps an	allocation, it adds two
	bytes to the requested size, and it places a specific bit pattern
	in the two last	bytes, right after the real allocated block.  
	When the block is freed, it checks whether these two bytes have
	been changed. 
	If one of these	locations has been changed, some code in your 
	program	has written beyond the end of an allocated heap	block.
	If you then select Verbose Data	Checking and rerun the program,	
	BOUNDS-CHECKER will check all allocated	blocks every time it 
	traps a	library.  Because the checking is not done on every 
	instruction, the line at which the overwrite is	detected is not
	the point at which it occurred,	but is somewhere just afterwards.
	Verbose	Data Mode slows	down operation of the program, so it
	should not be selected except when the message above indicates 
	that it	is needed.

      Probable Causes:
	- Use of a pointer that	has been freed.
	- Overrunning a	buffer in an allocated structure.
	- Copying the wrong kind of structure to a heap	block

      Recommended Action:  Re-run BOUNDS-CHECKER with the /VD option 
	enabled	to help	narrow down where the actual corruption	took 
	place.	Once you have narrowed it down,	sprinkle "free 
	((void *)0)" statements in the preceding code to narrow it down 
	further.  Freeing of a NULL pointer is ignored by the free 
	library, but is	trapped	by BOUNDS-CHECKER, which will then check 
	all the	allocated blocks for overruns.


	  *********************************************************
	  Your Program is being	overwritten from another program or TSR
	     Code Area is being	read from outside your program Area
	  Code Area is being overwritten from outside your program area
	  *********************************************************

      Description:  Another program or TSR is trying to	access the memory
	that belongs to	the code area of your program.

      Probable Causes:
	- A TSR	or program is accessing	your programs memory.
	- A caching program is in use
	- This error will also occur with some third party libraries that
	legally	write into the code area.

      Recommended Action:  Remove all caching programs and all TSR's not
	needed by your program from your system	configuration and run 
	BOUNDS-CHECKER again. If you still have	problems, you can add
	ACCESS ANYONE CODE-AREA	to your	exception file,	but doing so may 
	cause some actual problems to be ignored by BOUNDS-CHECKER.


	  *********************************************************
		      Allocation of Memory Failed
		    Re-Allocation of Memory Failed
	  *********************************************************

      Description:  A memory allocation	routine	has returned an	out-of-
	memory error code.  BOUNDS-CHECKER pops	up on out-of-memory 
	conditions so that you are aware of them: you should then verify 
	that your program handles this condition correctly.
	An out-of-memory error occurs when there is not	enough contiguous
	memory to allocate the block size requested.

      Probable Causes:
	- Not enough contiguous	memory left. If	your program does random
	allocation and freeing,	you may	have a condition where the heap
	has enough free	memory for the block, but it is	fragmented so
	that there is not enough contiguous memory.

      Recommended Action:  Remove any TSRs or other drivers that you do
	not need, and load the other drivers and TSR's high to free up 
	more contiguous	memory.	Also, reduce the number	of allocations
	your program is	doing.
	If your	program	tests for this type of error, or if your code
	determines how much heap space is available by allocating until	
	it runs	out, you can turn this checking	off by using the /NMF
	switch.


	  *********************************************************
		   Invalid Access to an	Interrupt Vector
	  *********************************************************

      Description:  When BOUNDS-CHECKER	loads, it write	protects all 
	memory except for that data and	stack areas of your program.  Any
	writes outside of this space will result in a BOUNDS-CHECKER 
	error.
	This error message is displayed	if your	program	attempts to do a
	word operation at an odd-numbered address within the Interrupt 
	Vector area in low memory. Because the Interrupt Vectors are all 
	word data, any access to an odd-numbered address is questionable.
	A word operation at an odd-numbered address, which spans two 
	separate words,	is highly questionable.

      Probable Causes:
	- You have an uninitialized pointer.
	- This is a legal access being made by your program

      Recommended Action:  Note	what source line caused	the error, exit	
	BOUNDS-CHECKER and find	the cause. If this is indeed a legal 
	access being made by your program, you can rerun the program, and
	when BOUNDS-CHECKER pops up, add an entry in the exception file	
	using the syntax:

	   Add Access Procedure	Location ( or Range ).


	  *********************************************************
			     Runaway Program
	  *********************************************************

      Description:  If you are using the /R option, BOUNDS-CHECKER pops	
	up whenever your program jumps or calls	outside	of its code area.
	Many programs deliberately jump	or call	outside	of their code 
	space.	This behavior is common	in overlay managers and	in 
	programs that communicate directly with	TSRs or	device drivers.

      Recommended Action: If this occurrence is	not a runaway program, 
	select the Log option so your program continues.  BOUNDS-CHECKER 
	will ignore all	further	dispatches to this address.
	If this	occurrence is a	runaway	program, use the Stack option to 
	find the area in the program where it lost track.


	  *********************************************************
			 Invalid Op-code Interrupt
	  *********************************************************

      Description:  "Invalid Op-code" means that the current instruction
	is an undefined	code (not a valid instruction) or is a protected-
	mode instruction which is not allowed within a real-mode program.
	Almost always this indicates that your program has jumped into
	a data area (not necessarily within your program space), and is	
	attemping to execute data as if	it were	instructions.

      Probable Causes:
	- A return address on the stack	was destroyed, so when the
	program	returned from a	procedure call,	it jumped to the wrong 
	place.
	- If you have allowed access to	your code area in the exception
	file, some critical code was overwritten.

       Recommended Action:  Use	the stack option to find the area where	
	 the error occurred, then eXit BOUNDS-CHECKER and fix the error.

      -------------------------------------------------------------------