Article # 86, added by Geoworks, historical record
| first | previous | index | next | last |

Debugging memory leaks using Swat.




Among the more common but difficult errors to find are pointers
to unlocked blocks. These can cause seemingly random memory
leaks because the block may not move immediately. The memory
manager only moves the block when it needs to.

To help you track down these errors, use Swat and set "ec
+segment +unlockMove" (+free and +lmemMove are also useful
in tracking down memory leaks). The segment flag will cause
the EC version of Geos to check the segment registers to
make sure they are valid. The unlockMove flag will cause
blocks to get moved whenever their lock count reaches zero.

If you call a routine with a parameter that is a pointer to
a unlocked block, you will get a death due to
ILLEGAL_SEGMENT. You can then do a regs, which will display
something like this:

  (someapp:0) 4 => regs
  AX a000h 40960  BX 5820h 22560  CX 00f4h  244
  DX cccch 52428  SI 170bh  5899  DI 0001h  1
  BP 0888h  2184  SP 0878h  2168

  CS  323fh  handle 1b30h (geos::ECCode)
  DS  170bh  handle 15d0h (geos::dgroup)
  SS  544eh  handle 55e0h (dgroup)
  ES  9dc9h  handle 5960h
  IP  01b6h  (geos::ECCode::ECCheckSegment+19)
  Flags: OF=0 DF=0 IF=1 TF=0 SF=0 ZF=1 AF=0 PF=1 CF=0

And from that you can do a phandle on the handle associated
with the ES and DS segment registers to see how many locks
are on the block. What you are looking for is a lock count
of zero like in the following example.

  (someapp:0) 5 => phandle 5960h
  address: 0x9dc9  size: 0x12  prev: 0x5890  next: 0x5a40
  owner: 0x2450 (notebk)  Swapable
  Locked 0 times  Last Use: 4214h  OtherInfo: 1h

Now you look at the pointer variables in your application to
see if any are pointing to the block. In the above example,
the pointer would point to 9dc9h:0000h.