[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference hydra::axp-developer

Title:Alpha Developer Support
Notice:[email protected], 800-332-4786
Moderator:HYDRA::SYSTEM
Created:Mon Jun 06 1994
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3722
Total number of notes:11359

3142.0. "IBR" by KZIN::ASAP () Wed Feb 05 1997 04:40

    Company Name :  IBR
    Contact Name :  Gerd Heupel
    Phone        :  0049 228 97985-0
    Fax          :  0049 228 97985-55
    Email        :  
    Date/Time in :   5-FEB-1997 09:40:00
    Entered by   :  Christopher Gibson
    SPE center   :  REO

    Category     :  nt
    OS Version   :  
    System H/W   :  


    Brief Description of Problem:
    -----------------------------

From:	ESSB::ESSB::MRGATE::"ILO::ESSC::dlennon"  5-FEB-1997 09:20:15.93
To:	RDGENG::ASAP
CC:	
Subj:	POINT No.18923, IBR (Germany)

From:	NAME: ESCTECH@ILO        
	TEL: (822-)6704        
	ADDR: ILO                <dlennon@ESSC@ILO>
To:	ASAP@RDGENG@MRGATE


Hello - 

POINT Log Number	

Company Name 	IBR	
						
Engineers name	Gerd Heupel	

Telephone Number	0049 228 97985-0

Fax Number		0049 228 97985-55

E-mail Address		N/A

Operating System, Version	Windows NT

Platform			Alpha 

Problem Statement		

Access Violation on Windows NT
A large executable (25 MB) runs inconsistently into an access violation. It
crashes after a few minutes processing. Under the exact same conditions, the
crash occurs with approx. every 2nd run. If the program is started in Visual
C++ in debugger mode, it doesn't crash. We suspect that the cause of the crash
is incorrect  memory management. If we start the debugger after the crash, the
cause of the crash has already occurred, and the error itself cannot be found. 

- Is there a possibility to continuously monitor the memory management (special
tool/library)?
- Are there other debug options?
- Have you other suggestions as to how to locate the error?

Regards,
Declan.
T.RTitleUserPersonal
Name
DateLines
3142.1Reply to customerRDGENG::moby.reo.dec.com::crgRent this space for your own messageFri Feb 07 1997 06:4993
Hi,

I fax'ed the following reply to the customer on 5th Febraury.
I haven't heard anything since so I've closed the call.

Christopher Gibson
SPE UK
[email protected]

--------cut here--------
Dear Gerd,

Re: ASAP Call

I have been given the details of the software development problem you
are experiencing with Windows NT on Alpha. If the problem is, as you
believe, related to memory management then you do have a number of
options.

"Is there a possibility to continuously monitor the memory management
(special tool/library)?"

The debug version of the C Run-Time Library does have support for a
debug heap. This is used by linking to the debug version of this
library. The debug heap free() routine checks to see if the application
has tried to use more memory than was allocated for the block. Other
checks can be performed from within your code. You can for example:

� Carry out a periodic check of the heaps integrity with a call to
  _CrtCheckMemory() (this can also be done automatically at every
  allocation and deallocation but will significantly affect
  performance)
� Check for memory leaks when the program exits
� Simulate low memory situations
� Dump the current state of the heap
� Track heap allocation requests to help identify errant code
� Add your own hooks to the debug code

For more information see the online Visual C++ documentation under:

   Visual C++ Books
      C/C++
         Run-Time Library Reference
            Debug Version of the C Run-Time Library
               Memory Management and the Debug Heap

There are also powerful third party tools available to help track down
memory management problems. One which is available for Intel and Alpha
is SmartHeap from MicroQuill Software Publishing, Inc. I have never
used this tool but its list of features looks comprehensive. Take a
look at their Web site to judge for yourself
(http://www.microquill.com/).

"Are their other debug options?"

There is a possibility that your program is running out of heap space,
particularly as it is so large. A tool called Pview can be used to help
check (see the online documentation for details).

Does your application check for NULL return values from malloc() or
new. The default is heap size 1 MB, but this can be changed with the
/HEAP link option.

"Have you other suggestions as to how to locate the error?"

You could include some structured exception handling in your
application. This allows you to trap errors and either handle them or
terminate gracefully. When your application traps an exception you can:

� Determine which exception which occurred
� Get the address where the exception occurred.

Once again see the online documentation for the try / except / finally,
GetExceptionCode(), and GetExceptionRecord().

You can find this under:

   SDKs
      Win32 SDK
         Win32 Programmers Reference
            Overviews
               System Services
                  Structured Exception Handling

See also C++ Exception Handling (the try, catch, and throw statements)
in the C++ Language Reference if you are using this language.

Yours sincerely,

Christopher Gibson
Software Partners Engineering
Digital Equipment Co. Limited