l|||||||||||||||||||||||l|||||||||||||||||||||||||||||||||||||||||||||l||||
`
`US()(J6634()2()B1
`
`(12) United States Patent
`Bates ct al.
`
`(10) Patent No.:
`
`(45) Date of Patent:
`
`US 6,634,020 B1
`Oct. 14, 2003
`
`$354,339
`5_.sm,tsr1e
`5,896,536
`s,9m__7o9
`5,949,972
`5,953;:3t1
`6,175,913
`5,249,907
`e,295_.o 13
`5,351,345
`
`A *
`A "
`A *
`A
`A
`A
`Bl
`Bl
`Bl
`Bl
`
`511998 Pardo eta].
`2f19‘J9 Lindsey
`4191909 Lindsey
`$1999 Cantey ct al.
`‘M999 Appiegate
`9,4999 Rishi et a1.
`“ U200} Chcstcrs ct al.
`*
`t:i;‘2t.)Ul Carter ct al.
`* W200} Bates et al.
`“
`2/‘Z002
`I-linker ct al.
`
`
`
`717.3129
`'1"l7t'l28
`71'.-‘I128
`395t?t.l5
`395;’l85.fl7
`39S,."'?f)4
`'1'l'1'.~"22T
`.. 717E129
`714.338
`717E128
`
`..
`
`(54)
`
`(75)
`
`UNINI'I‘IAl,IZI£l) MEMORY WATCH
`
`Inventors: Cary Lee Batw, Rochester, MN (US);
`Victor John Gettler, Lexington, KY
`(US)
`
`(73)
`
`Axsignce:
`
`International liusintss Machines
`Corporation, Armonk, NY (US)
`
`(*)
`
`Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`USC. 154(b) by 0 days.
`
`(31)
`
`(2?-)
`
`(51)
`(53)
`
`(58)
`
`(56)
`
`Appl. No.: 09,535,344
`
`I"-‘itedz
`
`Mar. 24, 2000
`
`
`
`Int. Cl.’
`U.S. Cl.
`
`G061‘ 91'44; GOGF 9,100
`7171131; 'r'17X124; 717E127;
`'r'17tl29; 717E130; 712E227
`717E124, 125,
`Field of Search
`71?'t12'r', 129, 130, 131; 71435, 37, 38,
`40, 42; 712K227, 24-4
`
`References Cited
`
`U.S. PA'l‘l£N'I' [)OCUM[-LNTS
`
`3953575
`':‘l4;'25
`..
`. 395f5‘r'S
`‘maze
`'1'D3,.’Z"i
`':‘14,1'38
`..
`.. 714,338
`?14;'53
`
`
`
`M1993 Hastings
`5,l93,l8() A
`3fl994 Prilzmow
`5,295,260 A *
`8;'l994- Hastings
`5,335,344 A
`8tl9<J5 Kiniclntan
`3,44c.__9r111 A *
`5,598,553 A " U19‘)? Richter et al.
`5,611,043 A “
`3;’l90? Even et :31.
`5,613,063 A *
`351997 Eustace et al.
`5__(344,?{l9 A *
`"M997 Austin
`
`402
`
`“ cited by examiner
`
`I’r£rnar_v Em.-m'ner—Gregory Morse
`A.s'.5't'.$tar1t Exm:rim3r—Eric B. Kiss
`or Fr'rm—Moser,
`(74) Attorrtey, Agertt,
`.P
`Sheridan, [_.I..
`
`(57)
`
`ABSTRACT
`
`Patterson
`
`64:
`
`In the present invention, a special purpose watch function is
`used to find reference to uninitialized memory within a
`computer program during debugging. The uninitiahzerl
`rnemory watch may be implemented singularly with respect
`to a given memory allocation or as a watchpoinl wherein a
`watch is set on a memory space for each instance of a
`memory allocation during execution of a program. At the
`point where this watch is set, the program assumes that the
`memory targeted is uninitiatized. When storage to the target
`memory is macle, the watch function marks that segment of
`memory as initialized and permits continued program execu-
`tion. Upon detecting a reference to the memory. a determi-
`nation is made as to whether the watched memory space is
`initialized.
`
`44 Claims, 7 Drawing Sheets
`
`APPLE 1008
`
`404
`SET BREAKPOINTS.
`SE'|'|'!NG
`WATCHES. WATCH
`
`CONTROL POINT
`POINTS OF!
`UNINITMLIZED
`
`MEMORY WATCHES
`405
`
`
`
`
`
`
`
`H-KNDLING
`CONTROL POINT
`
`
`
`
`
`4158
`
`UNINITIALIZED
`MEMORY
`WATCH
`7
`
`
`6
`
`PROCESS
`UNINITIALIZEO
`WATCH
`
`4l'D
`
`
`BREAKPOMITS
`ASSOCIATED WITH
`WATCH POINTS
`?
`
`
`SET UNINITTALEZED
`penronti
`
`
`
`MEMORY WATCH
`OTHER
`pnocessme
`
`
`
` ‘H4
`
`APPLE 1008
`
`1
`
`

`
`U.S. Patent
`
`Oct. 14, 2003
`
`Sheet 1 of 7
`
`US 6,634,020 B1
`
`
`
`s_<moom_n_mm.Sms_oo
`
`
`
`s_mB>mozF<mm¢o
`
`
`
`>mos_ms_Z_<_>_
`
`H
`
`
`
`Ews_zom_>zmoz__2s_<moomn_
`
`
`
`m_o.E:._<>mzo_mmm_mn_xm
`
`
`
`~_mEEmm_.—z_mnooo
`
`
`
`n_.~_mum:wnmmo
`
`
`
`mm_o<z<s_+z_on:¢mmm
`
`mm
`
`H.m.E
`
`
`
`mmnmzmwfinmmm
`
`
`
`$.52?n_O._.w
`
`
`
`
`
`w._m_<._.._.Z_On_._Om_._.ZOO
`
`
`
`n=_xmozflmz-n=_._<z_zmm.—_n=._mwéopwmm<_2
`
`%
`
`
`
`mo_>m_om_w<mo.rm
`
`
`
`mwm_oo<Emma.
`
`mm
`
`momwmoomm
`
`NH
`
`2
`
`
`
`
`
`
`

`
`m3P3U
`
`.4
`
`7...
`
`U
`
`4|.B020...
`
`
`
`._Ow_._.ZOOE...n_O._.wmum:oammommm_.._m<._.mm._oz<_._mo<n_mm._z_M._.Z_On_
`
`
`
`
`
`
`
`
`
`
`memmm.0<Z<__2mob3._<>mm,m_m_..E:m_SzwmmHz_on_v_<w.m_mzoawmmaxm
`
`
`
`
`
`
`
`m.6.,NMESI
`
`McmmmhE$.._w._.z_
`
`M...s_<moomn_mooon
`
`3
`
`

`
`LlneftaPQMU
`
`M,
`
`....l0m%
`
`7.
`
`1B023,4366..,
`
`
`
`
`
`
`
`mmo5m>:m_Emaoomwm_mn_n_<_2§_wom_n_mnooaom_Io.cssmmm_mon_<mmmssz
`
`
`
`
`
`
`
`
`
`
`
`Io._.<>>n_Ommo»mm:.2_on_mmimuxobss_._0._.<>>
`
`
`
`
`
`
`
` mmoooom395$mwnooommmmgfimwoooa
`
`mmmwmfi
`
`S.Uman
`
`
`
`Lrsflmfimwoooa4
`
`4
`
`

`
`U.S. Patent
`
`Oct. 14, 2003
`
`Sheet 4 of 7
`
`US 6,634,020 B1
`
`402
`
`
`400
`
`
`
`404
`
`SETTING
`CONTROL POINT
`?
`
`
`
`
`SET BREAKPOINTS,
`WATCHES, WATCH
`POINTS OR
`UNINITIALIZED
`MEMORY WATCHES
`
`
`
`405
`
`HANDLING
`
`CONTROL POINT
`
`
`
`?
`
`408
`
`
`UNINITIALIZED
`MEMORY
`
`WATCH
`
`?
`
`410
`
`PROCESS
`
`UNINITIALIZED
`
`
`WATCH
`
`
`
`
`
`BREAKPOINTS
`
`ASSOCIATED WITH
`
`
`
`WATCHPOINTS
`
`414
`
`SET UNINITIALIZED
`
`MEMORY WATCH
`
` PERFORM
`OTHER
`PROCESSING
`
`
`
`43”
`
`Fig. 4
`
`
`
`
`
`5
`
`

`
`U.S. Patent
`
`Oct. 14, 2003
`
`Sheet 5 of 7
`
`US 6,634,020 B1
`
`502
`
`504
`
`508
`
`ADD WATCH
`TO CP TABLE
`
`
`
`
`
`CALLED
`TO SET WATCH
`?
`
`
`
`ESTABLISH WATCH
`
`
`
`510
`CALLED
`
`HANDLE ALL OTHER
`TO SET
`BP MANAGER
`
`WATCH POI NT
`OPERATIONS
`'?
`
`
`
`
`
`
` MAP WATCHPOINT LOCATION TO
`ADDRESS IN PROGRAM AND
`
`SAVE IN CP TABLE
`
` GET OPCODE AT ADDRESS AND
`SAVE IN CP TABLE WITH
`
`ADDRESS
`
`
`
`
`SAVE DCODE PROGRAM IN
`CP TABLE WITH ADDRESS
`
`Fig. 5
`
`6
`
`

`
`m..waPQMU
`
`m,
`
`H......
`
`IBm3,M6.,6SU
`
`
`
`o3%.:Imss.E_on_:ob§>mm»m_mm_:>>_>_<moomn_z_mmm_mon_<50
`
`
`
`
`
`
`
`
`
`mmm_._.mmn_mm:.z_mooooj<o
`
`
`
`
`
`M_2<moomn_moooam_Somxm_
`
`z_ommokmm_ooon_omE3:sm_©%.~..:.~
`mwm_mn_n_<I._._>>m._m<»no.
`
`
`
`
`
`
`
`7
`
`

`
`5mm
`
`§
`
`ma
`
`
`
`m<O._.nmmo._.w
`
`
`
`..O._.om_m_o.5..
`
`
`
`wmt_,mxm<s_
`
` U.S.Patent
`
`o_n_
`
`
`
`mar.ID._.<>>
`
`n_OSsmmm9.
`
`OZ
`
`Oct.14,2003
`EmEu
`
`wmmohm4.
`
`m_><:
`
`omozmmmmmm
`
`
`
`omv_m<s_zmmmmmtrm
`
`
`
` 0..O._.m_mo»m__m<
`
`am_N_..<_:z_z:
`zmsmmas
`
`Em
`
`mm
`
`DmN_n_<E._Z_
`
`_._0._.<>>MI.»
`
`n_mN_._<Ez_
`
`
`
`ZKD._.wMww>
`
`m_
`
`
`
`>N_O_2m=._,__._._<
`
`
`
`I._._>>n_m.E_uomm¢
`
`m$_S
`
`EmIOH<>>
`
`
`
`>mn_m=._m_._mE.wm_._0.r<>>
`
`._.Z_On:._0.w<>>
`
`mm._az<_._
`
`m<..smo>._m<Soz_w
`
`aopm._._<U
`
`Sheet7of7
`
`._.Z_On_I0._.<>>
`
`
`
`EaID._.<..$m_>ozmx
`
`US6,634,020B1
`
`no.6._._<omom
`mm_._oz<_._
`
`
`
`8
`
`
`
`
`
`
`
`
`
`
`
`
`

`
`US 6,634,020 B1
`
`1
`UNINITIALIZEI) MEMORY WATCH
`
`BACKGROUND OF THE INVENTION
`
`l. Field of the Invention
`
`'Ihe present invention relates to computers and computer
`software. More specifically,
`the invention is generally
`related to debugging software.
`2. Background of the Related Art
`Inherent in any software development technique is the
`potential for introducing “bugs”. A bug will typically cause
`unexpected results during the execution of the program.
`Locating, analyzing, and correcting bugs in a computer
`program is a process known as "debugging." Debugging of
`programs may be done either manually or interactively by a
`debugging system mediated by a computer system. Manual
`debugging of a program requires a programmer to manually
`trace the logic flow of the program and the contents of
`memory elements, e.g., registers and variables. In the inter-
`active debugging of programs,
`the program is executed
`under
`the control of a monitor program (known as a
`“debugger”), commonly located on and executed by the
`same computer system on which the program is executed.
`Conventional debuggers typically support
`two primary
`operations to assist a computer programmer. Each operation
`allows the programmer to examine the state of program
`registers and variables at a given point in the execution of a
`program. A first operation supported by conventional debug-
`gers is a “step” function, which permits a computer pro-
`grammer to process instructions in a computer program at a
`source file level (i.e., line by line) and at a statement level,
`and see the results upon completion of each instruction.
`While the step operation provides a programmer with a large
`amount of information about a program during its execution,
`stepping through hundreds or thousands of program instruc-
`tions can be extremely tedious and time consuming. A
`programmer may be required to step through many program
`instructions that are known to be error-free before a set of
`instructions to be analyzed are executed.
`A second operation supported by conventional debuggers
`is a breakpoint operation. A“breakpoint” is a point in the
`program where execution of the computer program is
`stopped so that the state of the program can be examined by
`a computer programmer. As a result, when a computer
`program is executed by a debugger, the program executes in
`a normal fashion until a breakpoint is reached. The debugger
`then stops execution and displays the results of the computer
`program to the programmer for analysis.
`Most breakpoints supported by conventional debuggers
`are unconditional, meaning that once such a breakpoint is
`reached, execution of the program is always halted. Some
`debuggers also support the use of conditional breakpoints,
`which only halt execution of a program when a variable used
`by the program is set to a predetermined value at the time
`such a breakpoint is reached.
`Typically, step operations and breakpoints are used
`together to simplify the debugging process. Specifically, a
`common debugging operation is to set a breakpoint at the
`beginning of a desired set of instructions to be analyzed, and
`then execute the program. Once the breakpoint is reached,
`the program is halted, and the programmer then steps
`through the desired set of instructions line by line using the
`step operation. Consequently, a programmer
`is able to
`isolate and analyze a particular set of instructions without
`having to step through irrelevant portions of a computer
`program.
`
`I0
`
`15
`
`30
`
`40
`
`50
`
`55
`
`60
`
`65
`
`2
`One of the most difficult problems to debug is when a
`program reads from uninitialized memory. As a program
`code is converted into binary instructions, memory for
`variables is set aside. Uninitialized memory refers to
`memory that
`is not given initial values. Problems with
`uninitialized memory can manifest themselves in dilferent
`ways, costing loss of programmer productivity. For
`example, variables may be assigned random values when
`they are uninitialized that cause errors which are not imme-
`diately transparent.
`Orie attempt to debug memory-related errors is to pur-
`posefully introduce a "funny value,” or garbage, into the
`memory. In some cases, the funny value will be utilized
`during the execution of the program and result in output
`alerting the programmer to a potential memory related
`problem. However, in practice, the funny value selected by
`the programmer does not necessarily produce an expected
`error. Thus, the programmer can never be certain that a given
`output is the result of the funny value being accessed from
`memory.
`In addition, even when recognizable output
`is
`produced, the output often does not occur until much later in
`the execution of the program relative to when the funny
`value was actually used. Thus, the programmer is unable to
`determine where in the source code the error is located.
`Another method which can be used to locate the location
`of a read from uninitialized memory limited situations is a
`compiler generated warning message notifying the user of
`the reference to the memory. However, this method does not
`detect all references to uninitialized memory. This limitation
`results because modules are compiled separately so the
`compiler doesn’t “know" what variables may be set by a call
`to a procedure in another module. Further, variable values
`that alfect control flow can come from sources external to
`the compiler such as data files and user input. As a result, it
`is impossible for the compiler to diagnose anything but the
`simplest of situations where a variable is referenced before
`its value is set.
`
`In another method, referred to herein as the “object code
`insertion" ("OCI") method, checking instructions are
`inserted in the program’s object files, between instructions
`that reference memory, to monitor the program’s memory
`reads and writes. The executable contains a call to malloc
`and a reference of the allocated memory. After the call to
`malloc and before the following memory-reference
`instruction, control transfers to a checking function and then
`returns at its conclusion to the original executable. This
`method also uses a malloc wrapper to monitor the program’s
`memory allocations and frees.
`One problem with the OCI method is that it requires a
`special build of the program, in which checking instructions
`are inserted between the program’s normal instructions. The
`OCI method also suffers from performance degradation
`because performing a function call and looking up data
`structures during every memory-reference instruction in a
`program will necessarily have a severe impact on perfor-
`mance. Experienced users may often intuit that uninitialized
`memory is being referenced. In this case, the users don’t
`require that all memory being allocated in the program be
`tested as is done with the OCI method. Rather,
`the user
`requires a method and apparatus to pinpoint
`the exact
`location of the reference on the suspect memory space.
`Moreover, the OCI method perfonns function calls and
`data structure references in-between a program’s normal
`instructions, which results in poor locality and few cache
`bits on modern CPU architectures that utilize on-chip
`caches, resulting in further performance degradation.
`In
`
`9
`
`

`
`US 6,634,020 B1
`
`3
`addition, the OCI method provides excessive information.
`requiring more overhead time on the part of the user to sift
`through the output data to locate relevant information.
`Therefore,
`there is a need for a debugging program
`adapted to address the problems associated with uninitial-
`ized memory.
`SUMMARY OF TI-IE INVI:'.N'I‘lON
`
`invention generally provides an apparatus,
`The present
`program product. and a method for debugging computer
`programs that monitors reads and writes to uninitialized
`memory.
`In one aspect of the invention, a method for debugging
`code is provided, comprising. setting an uninitialized
`memory control point on at
`least one memory space,
`wherein the uninitialized memory control point is adapted to
`cause detection of a reference to the memory space during
`execution of the code. When the reference is made to the
`memory space during execution of the code, the method
`determines whether the memory space is initialized; and if
`the memory space is not initialized when the reference is
`made, a result is returned to a user interface indicating that
`the reference was made.
`
`I0
`
`15
`
`4
`and can be understood in detail, a more particular descrip-
`tion of the invention, brielly summarized above, may be had
`by reference to the embodiments thereof which are illus-
`trated in the appended drawings.
`It is to be noted, however, that the appended drawings
`illustrate only typical embodiments of this invention and are
`therefore not to be considered limiting of its scope, for the
`invention may admit
`to other equally eflbctive embodi-
`]'l’lEl']lS.
`
`is a high-level diagram of a computer system
`1
`FIG.
`consistent with the invention.
`
`FIG. 2 is a block diagram of an exemplary debugger
`software environment.
`
`FIG. 3 is a data stmeture of a control point table.
`FIG. 4 is a flow diagram of a control point manager
`H)lJlll']C.
`
`FIG. 5 is a flow diagram of a control point manager
`routine for setting and handling uninitialized memory
`watches and watchpoints.
`FIG. 6 is a flow diagram illustrating one embodiment for
`setting uninitialized memory watches for a watchpoint.
`FIG. 7 is a How diagram of the uninitialized memory
`watch and watchpoint processing routine.
`DI:l'l'AII..l_iD Dl:lSCRlP'I'lON OF Tl-ll}.
`PREFERRED EMBODIMENT
`
`The preferred embodiment of the present invention gen-
`erally provides a method and apparatus for debugging
`computer programs. Debugging computer programs is aided
`by identifying, setting and monitoring uninitialized memory
`watches and uninitialized memory watchpoints {also
`referred to herein as “watchpoints”). An uninitialized
`memory watch is a control point set by a user on a specific
`memory space to determine when a reference {reads and
`writes) is made to the memory prior to initialization. Watch-
`points are control points inserted into a computer program
`which set an uninitialized memory watch for each instance
`the watchpoint address is hit. The uninitialized memory
`watches then monitor reads and writes to memory which is
`assumed to be uninitialized at the time of allocation.
`
`Once a watch for uninitialized memory is established, this
`capability may enhance a debug user interface in a number
`of possible manners. For example, uninitialized memory
`addresses may be highlighted. Also, program execution may
`be halted once a load to an uninitialized memory is made and
`the user informed of the memory location and the location
`in the program the load occurred.
`By monitoring references to uninitialized memory, a
`number of advantages are realized. For example, the user
`can quickly determine the point in a program where refer-
`ences to uninitialized memory occurs and can debug it
`directly. The “real-time” debugging capability obviates
`latent problems which would otherwise surface later during
`the execution of the program. In one embodiment, the user
`may be informed about watches that are removed as memory
`is initialized and resources associated with the watch are
`removed.
`
`Referring now to FIG. 1, a computer system 10 consistent
`with the invention is shown. For purposes of the invention,
`computer system 10 may represent any type of computer,
`computer system or other programmable electronic device,
`including a client computer, a server computer, a portable
`computer, an embedded controller, etc. The computer sys-
`tem lfl may be a standalone device or networked into a
`larger system. In one embodiment, the computer system 10
`
`In another aspect of the invention, a method for debug-
`ging code is provided, comprising, allocating at least one
`memory space having a memory address range and setting _
`an uninitialized memory watch on the memory space, which
`is triggered when a reference is made to the memory space.
`If the reference is a write, a first Dcode is executed to mark
`the memory space as initialized. If the reference is a read, a
`second Dcode is executed to determine whether the memory
`space is initialized. If the memory space is not initialized
`when the read is made, a result is returned to a user interface
`indicating the reference.
`In another aspect of the invention, a program product
`comprising a computer readable medium bearing at debug- -
`ging program is provided. When executed the debugging
`program causes steps to be performed, the steps comprising,
`allocating at
`least one memory space in a memory and
`setting an uninitialized memory watch on the memory space.
`which is triggered when a reference is made to the memory
`space during execution ofa target program. If the reference
`is a write, a first Dcode is executed to mark the memory
`space as initialized. If the reference is a read, a second
`Dcode is executed to determine whether the memory space
`is initialized. If the memory space is not initialized when the
`read is made, a result is returned to a user interface indicat-
`ing the reference.
`In another aspect of the invention, a computer system
`comprising a memory and a processor configured for pro-
`viding a system exception in response to references to the
`memory is provided wherein a method debugging a program
`is executing in the processor. The method comprises allo-
`eating at least one memory space in the memory; setting an
`uninitialized memory watch on the memory space, wherein
`when a reference is made to the memory space the unini-
`tialized memory watch is triggered and causes the processor
`to provide the system exception; executing, by the processor.
`a first Dcode to mark the memory space as initialized if the
`reference is a write; and executing, by the processor, a
`second Dcode to determine whether the memory space is
`initialized if the reference is a read. If the memory space is
`not initialized when the read is made, a result is returned to
`a user interface indicating the reference.
`BRIIL-21"" DESCRlP'l'I(JN OI? THE DRAWINGS
`
`30
`
`40
`
`50
`
`55
`
`60
`
`65
`
`So that the manner in which the above recited features,
`advantages and objects ofthe present invention are attained
`
`10
`
`10
`
`

`
`US 6,634,020 B1
`
`5
`is an /\Sr'400 available from International Business
`Machines of Amionk, N.Y.
`Computer system 10 is shown for a multi-user program-
`ming environment that includes at least one processor 12,
`which obtains instructions, or operation codes, (also known
`as op codes), and data via a bus 14 from a main memory 16.
`The processor 12 could be a PC-based server,
`a
`minicomputer, a midrange computer, a mainframe computer,
`etc. adapted to support the debugging methods, apparatus
`and article of manufacture of the invention. In particular, the
`computer processor 12 is selected to support monitoring of
`memory references according to user-issued commands.
`One method of monitoring memory supported by various
`processors known in the art is a "watch.” As used herein, a
`watch is a hardware directed event such that when memory
`is modified, by a store for example, the watch will lire. Such
`a watch does not require a modification of object code. This
`mechanism is used to advantage by the present invention.
`Thus, the processor 12 is watch-enabled. Illustratively, the
`processor is a PowcrPC available from International Busi-
`ness Machines of Armonk, NY.
`'lhe main memory 16 includes an operating system 18, a
`computer program 20, and a programming environment 22.
`The main memory 16 could be one or a combination of
`memory devices, including Random Access Memory, non-
`volatile or backup memory, (e.g., programmable or Flash
`memories, read-only memories, etc.). In addition, memory
`16 may be considered to include memory physically located
`elsewhere in a computer system 10, for example, any storage
`capacity used as virtual memory or stored on a mass storage
`device or on another computer coupled to the computer
`system 10 via bus 14.
`The programming environment 22 facilitates debugging
`the computer program 20, or computer code, by providing
`tools for locating, analyzing and correcting faults. One such
`tool is a debugger program 23 that comprises a debugger
`user interface 24, expression evaluator 26, Dcode interpreter
`29, control point manager (referred to herein as “breakpoint
`manager 30”), control point table 32, debugger stop handler
`34, and result buffer 36. In one embodiment, the debugger
`23 is a Vtsua1Age® for Java'”‘‘ debugger modified according
`to the invention. Visual/\ge® for Java” is available from
`International Business Machines of Armonk, NY.
`The computer system 10 could include a number of
`operators and peripheral systems as shown, for example, by
`a mass storage interface 36 operably connected to a direct
`access storage device 38, by a terminal interface 40 operably
`connected to a terminal 42, and by a network interface 44
`operahly connected to a plurality of networked devices 46.
`The terminal 42 and networked devices 46 could be desktop
`or P(T—based computers, workstations, or network terminals,
`or other networked computer systems.
`the
`In general,
`the routines executed to implement
`embodiments of the invention, whether implemented as part
`of an operating system or a specific application, component,
`program, object, module or sequence of instructions will be
`referred to herein as "computer programs," or simply "pro-
`grams.” The computer programs typically comprise one or
`more instructions that are resident at various times in various
`memory and storage devices in a computer. and that, when
`read and executed by one or more processors in a computer,
`cause that computer to perform the steps necessary to
`execute steps or elements embodying the various aspects of
`the invention. Moreover, while the invention has and here-
`inafter will be described in the context of fully functioning
`computers and computer systems, those skilled in the art will
`
`it)
`
`15
`
`“
`
`30
`
`35
`
`40
`
`45
`
`50
`
`_
`
`60
`
`65
`
`6
`appreciate that the various embodiments of the invention are
`capable of being distributed as a program product
`in a
`variety of forms, and that
`the invention applies equally
`regardless of the particular type of signal bearing media used
`to actually carry out the distribution. Examples of signal
`bearing media include, but are not
`limited to, recordable
`type media such as volatile and nonvolatile memory devices,
`floppy and other removable disks, hard disk drives, optical
`disks (e.g., CD-ROM’s, DVD‘-s, etc.), among others, and
`transmission type media such as digital and analog commu-
`nication links.
`
`In addition, various programs and devices described here-
`inafter may be identified based upon the application for
`which they are implemented in a specific embodiment of the
`invention. However, it should be appreciated that any par-
`ticular program or device nomenclature that follows is used
`merely for convenience, and the invention is not limited to
`use solely in any specific application identified andfor
`implied by such nomenclature.
`The operational relationship of the debugger program 23
`may be understood with reference to FIG. 2 which provides
`an exemplary software environment for the computer system
`I0 of FIG. 1. The debugging capability is illustrated in block
`diagram form, with the elements shown that contribute to
`maintaining control points (e.g., creating and deleting) and
`to responding to a system exception. Although shown as
`separate components, it is understood that one or more of the
`cornponenLs may be combined. A debugging process is
`initiated by the debug user interface 24. The user interface
`24 presents the program under debugging and highlights the
`current line of the program on which a stop or error oceu rs.
`The user interface 24 allows the user to set control points,
`display, and change variable values by inputting the appro-
`priate commands. The control points of the present invention
`include watches and watchpoints set on memory spaces. The
`watches and watchpoirtts are configured to monitor reads
`(loads) and writes (stores) made to memory and [rigor a
`response notifying a user of reads from uninitialized
`memory. In some instances, the user may define the control
`points by referring to high-order language (I-I01.) references
`such as line or statement numbers or software object refer-
`ences such as a program or module name, from which the
`physical memory address may he cross referenced.
`The expression evaluator 26 parses the debugger com-
`mand passed from the user interface 24 and uses a table
`generated by a compiler to map the line number in the
`debugger command to the physical memory address in
`memory 16. In addition, the expression evaluator 26 gener-
`ates a Dcode program for the command. The Dcode program
`is machine executable language that emulates the com-
`mands. Some embodiments of the invention include Dcodes,
`which when executed, set watches and watchpoints as will
`be described in more detail below.
`
`The Dcode generated by the expression evaluator 26 is
`executed by the Dcode interpreter 28. The interpreter 28
`handles expressions and Dcode instructions to set control
`points and perform other debugging steps. Results from
`Deode interpreter 28 are returned to the user interface 24
`through the expression evaluator 26. In addition, the Dcode
`interpreter 28 passes on control point
`information to the
`breakpoint manager 30, which takes steps to set (and later
`handle) the control points and update the control point table
`32. In addition, the breakpoint manager 30 sets and handles
`conventional debugging control points such as breakpoints.
`After the control points are set, the user provides an input
`that resumes execution of the program 20. Execution of the
`
`11
`
`11
`
`

`
`US 6,634,020 B1
`
`7
`program eventually results in an encounter of a control
`point. The breakpoint manager 30 is then called and refer-
`ences the control point table 32 in order to determine the
`type of control point encountered and the associated pro-
`cessing. The breakpoint manager 30 then calls the stop
`handler 34 and program execution is halted. The stop
`handler 34 is a code segment
`that returns control to the
`appropriate user interface. This allows programming in an
`operation having multiple interfaces. The stop handler 34
`prompts the debug user interface 24 and may pass the results
`to the user interface 24. Alternatively, the results may be
`passed to the result bufier 36 to cache data for the user
`interface 24.
`
`10
`
`8
`As will be described in detail below, a first phase of the
`watchpoint involves setting a control point which, when
`triggered, calls the debug program 23. In one embodiment,
`the processing logic for setting the control points in the lirst
`phase of a watchpoint involves the same or similar logic to
`that used for setting breakpoints. For clarity,
`the control
`points set in the first phase of a watchpoint are referred to
`herein as breakpoints (the address for the breakpoints asso-
`ciated with a watch point are stored in the breakpoint address
`field 32:3}. in a second phase, an uninitialized memory watch
`is set and associated with the memory address specified by
`the watchpoint. This address is stored to the watch address
`field 32b. The entry for the second watch (watch 2) illus-
`trates the state of the control point table 32 entry after a
`watchpoint has been set and handled (i.e., encountered
`during the execution of the program 20), resulting in a watch
`being set on the associated memory. Thus, all fields are
`filled. Further, because a watchpoint can be fired multiple
`times (one for each time the associated breakpoint
`is
`encountered), multiple entries exist for the second watch.
`Fields 32d-g contain the same information because a watch-
`point is set for a given address (represented by the infor-
`mation in the breakpoint address field 32.9) in the code being
`debugged. Field 32!:
`is necessarily different because new
`memory will be allocated each time the code on which the
`watchpoint
`is set
`is executed. The "number of bytes
`watched” field 32c will typically be the same. Ilowever, in
`a dynamic environment, such as one using Java“, the entry
`for field 326 may vary for each instance a given watchpoint
`is fired. The entry for the third watch (watch 3} illustrates the
`state of the control point table 32 after a hreakpoint has been
`set for a watchpoint but before being handled (i.e.,
`encountered}. Thus, the fields 32b—c are empty. The fields
`32b—c' will be tilled upon encountering the breakpoint.
`It should be appreciated that the table 32 is merely for
`illustration. Other embodiments would provide fewer or
`more control point data fields. For example, the table 32 may
`also contain information for conventional control points
`such as breakpoints. In addition, this information could be
`contained in two or more data structures rather than in a
`single data structure.
`Referring to FIG. 4, a method 400 illustrating the opera-
`tion ofthe breakpoint manager 30 is shown. The method 400
`provides for maintaining control points and responding to a
`system exception, although the breakpoint manager may
`include other routines. The method 400 is entered at step
`402, which may correspond to any event calling the break-
`point manager 30. At step 404 a determination is made as to
`whether the event is setting a control point. Ifso, then at step
`406 the breakpoint manager 30 takes steps to set the appro-
`priate control point (e.g., uninitialized memory watches or
`watchpoints). The method 400 then exits at step 430.
`Referring now to FIG. 5, an embodiment of a method 500
`for setting uninitialized memory watches and watchpoints
`(step 406 of FIG. 4) is shown. At the time either control point
`is set, the memory space at issue is assumed to be unini-
`tialized. Uninitialixed memory refers to allocated memory
`that has not been given an initial value as a result ofa storage
`action to the memory.
`The method 500 is entered at step 502. At step 504 the
`method 500 queries whether the breakpoint manager 30 has
`been called to set an uninitialized memory watch. If so, the
`method 500 establishes a watch at step 506. Setting the
`watch is initiated by the user (programmer) who simply
`stops the program 20 at a point where memory hasjust been
`allocated, such as after a malloc( ) statement or at the end of
`a user supplied allocator. The user then sets an uninitialized
`
`15
`
`.
`
`30
`
`35
`
`40
`
`45
`
`50
`
`information is
`the control point
`In one embodiment,
`contained in a data structure such as control point table 32.
`An illustrative control point table 32 is shown in FIG. 3.
`Fields provided for each watch record include a watch
`number 32:: and the address field 32b containing the base
`address of the physical memory location being watched. The
`watch number 32:: provides a convenient identifier for a
`particular watch which has been set by the breakpoint
`manager 30. The address field 32!; may correspond to the
`location of any memory type including static memory (e.g.,
`for global variables), dynamic memory (e.g., heap memory)
`and automatic memory (e.g., stack memory). The address _
`field 32b is referenced when a system exception occurs at a
`specific address. If the specific address is in the control poi