Runtime Memory Checking

runtimechecks
Who took my memory?

Your app has gone through the development cycle, gotten tested, and finally it gets deployed. Everything goes well, but one day a customer calls you, "Hey, your binary is taking up 60Gig of memory, and there is nothing left!".  Instead of mumbling "then how do you remember my number?", you send a field application engineer to track down the problem at the customer site.

There is no debug information available and you cannot recompile your binary in the customer site. How to find the leaks? Here is where dbx's runtime memory checking (RTC) comes in handy. RTC interposes and instruments the binaries on the fly and therefore it does not require recompiling, relinking or even debug information - just load your application into dbx and run. For example,

% dbx a.out
(dbx) check -all                                                           
access checking - ON
memuse checking - ON
(dbx) run

You can also enable runtime memory checking on a running process using the link auditor.

% which dbx
/opt/ss12/opt/SUNWspro/bin/dbx
% setenv LD_AUDIT_64 /opt/ss12/opt/SUNWspro/prod/lib/amd64/dbxruntime/rtcaudit.so
% a.out &
[1] 6759
% unsetenv LD_AUDIT_64
% dbx -  6759
(dbx) check -all                                                           
access checking - ON
memuse checking - ON
(dbx) cont

When access checking is turned on, RTC detects and reports the following kinds of errors:

        baf     # Bad free
        duf     # Duplicate free
        maf    # Misaligned free
        mar    # Misaligned read
        maw   # Misaligned write
        oom    # Out of memory
        rua     # Read from unallocated memory
        rui      # Read from uninitialized memory
        wro    # Write to read-only memory
        wua    # Write to unallocated memory

With leaks checking, RTC will report the following kinds of errors:

        aib     # Possible memory leak - only pointer points in the middle of the block
        air     # Possible memory leak - pointer to the block exists only in register
        mel   # Memory leak - no pointers to the block

RTC reports memory errors with context information that includes details about allocation of a heap block. Here is a memory access error reported on an AMD64 box:

Read from unallocated (rua):
Attempting to read 1 byte at address 0x412de0
    which is just past heap block of size 1000 bytes at 0x4129f8
This block was allocated from:
        [1] rua() at line 37 in "access.c"
        [2] access() at line 7 in "access.c"
        [3] main() at line 7 in "main.c"

stopped in rua at line 38 in file "access.c"
   38           c = s[1000];

Memory errors can be suppressed. The following command suppress read from uninitialized (rui) in all functions in a.out

(dbx) suppress rui in a.out

RTC instruments memory access assembly instructions for access checking. You can exclude load objects, object files and functions from being instrumented. The following command

(dbx) rtc skippatch a.out -f main

excludes the function main from being instrumented.

Runtime memory access checking and leaks checking are available on Solaris Sparc and Intel x86/x64. AMD64 access checking is a new feature in Sun Studio 12. This advanced feature is fully supported by the debugger IDE.


Comments:

Hi, your blog about dbx rtc is good. I use that feature and it is very helpful. I have a doubt regarding dbx. can you please answer that? I used to work on Linux for development environment. But, now I am using solaris just because of great tools like Dtrace, dbx rtc etc. For easy migration from gdb to dbx, I have put aliases in .dbxrc file like alias c=cont, alias n=next. In gdb, if we press enter, automatically previous command is executed. Is there configuration setting or anything like that to do the same thing in dbx? Because, I feel that, this is the only feature that I am missing in dbx when compared to gdb. In rest of the cases, I feel dbx is superior to gdb. Thanks Durga Prasad

Posted by DP on June 01, 2007 at 08:56 PM PDT #

Yes, there is a gdb-compatible mode in dbx that supports repeated execution of the previous command. This mode can be entered and exited via dbx commands "gdb on" and "gdb off", respectively.

Posted by wpan on June 02, 2007 at 09:14 AM PDT #

Does dbx team plan to support 'enter pressing' feature in the near future? It seems that it is high required feature for user migrate from gdb to dbx. I has such kind feeling also when I try dbx at the first time, even though now I have accustomed to not using it. 'gdb on' is helpful, but sometime I need use switch on and off, it is a little tedious. and I am wondering how many people who like to use dbx will use 'gdb on'.

Posted by yydzero on June 02, 2007 at 12:04 PM PDT #

The original idea of adding a gdb-compatible mode in dbx was indeed to help make transition from gdb to dbx a little bit easier. It's not intended to be long-term. Over the years, several gdb specific features got added to dbx, the support of seperate debug file being the latest. And making this "enter pressing" feature available in dbx is being discussed but not yet planned. BTW, there is a RFE which asks for this very feature be added to dbx without entering a special mode.

Posted by wpan on June 03, 2007 at 04:52 AM PDT #

A very help peice of information, it did help a lot as I do not normally use dbx.

Thanks

Rick

Posted by Rick Sivernell on November 20, 2007 at 11:55 PM PST #

It was a very nice idea! Just wanna say thank you for the information you have shared. Just continue writing this kind of post. I will be your loyal reader. Thanks again.
~

Posted by links of london jewellery on November 21, 2009 at 12:41 PM PST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

janitor

Search

Top Tags
Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today