libumem - Memory Debugger, Memory Corruption and Memory Leaks

I am currently entangled with a particularly nasty memory corruption on my application. So I am using the libumem memory allocation utility to try and track it down. Since I am not an expert in this area I am going to write this blog in the hope that it helps me retain some information as well as proving useful to others out there.

The first thing I found to be of use was the following blog on sun.com. This gave a decent overview of memory buffer structures.

http://blogs.sun.com/amith/entry/detecting_memory_corruption_with_libumem

My problem manifested itself as a core dump in my application, written in C. I had turned the libumem utility to help me analyse the problem. Here are the steps I followed:-

1) Ran my test.

2) Generated a core file for analysis

gcore

3) Opened the core file for analysis
mdb

4) Ran the ::umem_verify utility and got the following (output here is truncated for clarity):-

umem_alloc_80 72a708 clean
umem_alloc_96 72aa88 1 corrupt buffer
umem_alloc_112 72ae08 clean

5) so I looked a little closer at the corrupted address :-

> 72aa88::umem_verify
Summary for cache 'umem_alloc_96'
buffer fcbe40 (free) seems corrupted, at 0

6) And so I looked event further into the buffer address provided by this command.

7) fcbe40::bufctl_audit

ADDR BUFADDR TIMESTAMP THR LASTLOG CONTENTS CACHE SLAB NEXT DEPTH
00fcbe40 deadbeef deadbeef00000000 deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
0xdeadbeef
0xdeadbeef
0xdeadbeef
0xdeadbeef
0xdeadbeef
0xdeadbeef
0xdeadbeef
0xdeadbeef
0xdeadbeef
0xdeadbeef
0xdeadbeef
0xdeadbeef
0xdeadbeef
0xdeadbeef
libACE.so.5.4.0`__1cGACE_OSEexit6Fi_v_+0x2

8) The following command was then used to print out 10 4-byte hex values starting at the memory address 100197f60 with X setting the format to hex> fcbe40/24X
0xfcbe40: deadbeef deadbeef deadbeef deadbeef deadbeef 0 deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef

Ok, the deadbeef suggests that the memory area has been freed but the '0' which stands out like a sore thumb here suggests that a '0' has been allocated to this area of memory after it has been.

We can ignore the first two 'deadbeefs' here as that represents the metadata part of the memory buffer.

9) What I then did was print out the umalog to see what actions had been carried out on this buffer. The first line here will redirect output to a file (mdb.log)

> ::log -e mdb.log
> ::umalog

10) I then grepped the file for the buffer fcbe40. This actually showed me where the area of memory was last freed. I looked at the structure which was being freed. Each field in the structure was 4 bytes long. So I looked at the fourth field (1 - deadbeef, 2 - deadbeef, 3 - deadbeef, 4 - 0) and then looked at my code to see where it was being used.

Lo and behold, I found that the field was being set after the memory was being freed.

Comodo vs ZoneAlarm firewalls

Well I recently patched ZoneAlarm on my Windows PC (running Windows XP Professional). This was as a result of being informed by ZoneAlarm that a patch was available and should be installed. I duly obliged.

Straight away a major problem was uncovered. The machine refused to boot and always reported an error. The error was NO_MORE_IRP_STACK_LOCATIONS reported via the Blue Screen of Death.

To resolve the issue I carried out the following.

1) Booted Windows XP in Safe Mode
2) Uninstalled ZoneAlarm (simple enough - the option is available under the Programs->ZoneAlarm drop down list).
3) Restarted computer.

What I noticed IMMEDIATELY was my machine ran MUCH faster than it has done for a long time. Now, I simply put my machine's poor performance down to an old processor being asked to do too much but it is now very apparent that it was ZoneAlarm that was causing the grind all along.

Of course, not wanting to be without a software firewall I hunted around and installed Comodo. Even with Comodo in place my old PC is now enjoying a new lease of life.

I would recommend that anyone who is having performance issues with a PC running ZoneAlarm, that they uninstall ZoneAlarm and see for themselves the difference it will make....

The Rich Jerk Scam

It seems that the Rich Jerk (Kelly Felix by name apparently) Scam is so subtle that they are even trying to put fake positive reviews online.

Here are a few links to what seems to be genuine reviews of the 'product'.

Again, the old maxim "If it sounds to good to be true it probably is" is as solid today as it ever was.

Rich Jerk Fake Reviews

Issue with O2's 3G network and the Palm Pre

I have experienced a new(ish) problem with my Palm Pre. It only seems to occur when the Pre has registered with O2's 3G network. The reception for the 3G network in Belfast is flaky to say the least and the problems I am seeing manifest themselves as follows:-

1) Inability to send SMS'. I get the following error message (which is a GSM timeout code I believe).

'Message failed to:XXXXXXXXXXX Could not send your message due to network error. Try again. (code:31)'

2) Inability to receive calls - all incoming calls are diverted straight to voicemail.

3) Inability to make calls - nothing but 'dead air' is heard on the Pre.

The issue is currently being actively discussed on two forums. It has been mentioned on the Palm Pre forum (by yours truly) but no other posters have replied.

PreCentral Forum

O2 Forum

Palm Forum