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.