http://www.cyberciti.biz/tips/howto-find-memory-used-by-program.html 

Linux find the memory used by a program / process using pmap command

by VIVEK GITE on NOVEMBER 20, 2007 · 18 COMMENTS

You can find the memory used by a program (process) by looking into /proc directory or using standard command such as ps or top. However, you must calculate all memory usage by hand i.e. add Shared Memory + mapped file + total virtual memory size of the process + Resident Set Size + non-swapped physical memory used by process.

So how do you find the memory used by a process or program under Linux? Use a tool called pmap. It reports the memory map of a process or processes.

pmap examples

To display process mappings, type
$ pmap pid
$ pmap 3724
Output:

 3724:   /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf 0000000000400000    164K r-x--  /usr/sbin/lighttpd 0000000000629000     12K rw---  /usr/sbin/lighttpd 000000000bb6b000   4240K rw---    [ anon ] 00000035ee600000    104K r-x--  /lib64/ld-2.5.so 00000035ee819000      4K r----  /lib64/ld-2.5.so 00000035ee81a000      4K rw---  /lib64/ld-2.5.so 00000035eea00000   1304K r-x--  /lib64/libc-2.5.so 00000035eeb46000   2048K -----  /lib64/libc-2.5.so 00000035eed46000     16K r----  /lib64/libc-2.5.so 00000035eed4a000      4K rw---  /lib64/libc-2.5.so 00000035eed4b000     20K rw---    [ anon ] 00000035eee00000      8K r-x--  /lib64/libdl-2.5.so 00000035eee02000   2048K -----  /lib64/libdl-2.5.so ..... .... 00002aaaac51e000      4K r----  /lib64/libnss_files-2.5.so 00002aaaac51f000      4K rw---  /lib64/libnss_files-2.5.so 00007fff7143b000     84K rw---    [ stack ] ffffffffff600000   8192K -----    [ anon ]  total            75180K

The -x option can be used to provide information about the memory allocation and mapping types per mapping. The amount of resident, non-shared anonymous, and locked memory is shown for each mapping:
pmap -x 3526
Output:

 3526:   -bash Address           Kbytes     RSS    Anon  Locked Mode   Mapping 0000000000400000     700       -       -       - r-x--  bash 00000000006ae000      40       -       -       - rw---  bash 00000000006b8000      20       -       -       - rw---    [ anon ] 00000000008b7000      32       -       -       - rw---  bash 00000000098de000     536       -       -       - rw---    [ anon ] 00000035ee600000     104       -       -       - r-x--  ld-2.5.so 00000035ee819000       4       -       -       - r----  ld-2.5.so 00000035ee81a000       4       -       -       - rw---  ld-2.5.so 00000035eea00000    1304       -       -       - r-x--  libc-2.5.so 00000035eeb46000    2048       -       -       - -----  libc-2.5.so 00000035eed46000      16       -       -       - r----  libc-2.5.so 00000035eed4a000       4       -       -       - rw---  libc-2.5.so 00000035eed4b000      20       -       -       - rw---    [ anon ] 00000035eee00000       8       -       -       - r-x--  libdl-2.5.so 00000035eee02000    2048       -       -       - -----  libdl-2.5.so 00000035ef002000       4       -       -       - r----  libdl-2.5.so 00000035ef003000       4       -       -       - rw---  libdl-2.5.so 00000035ef600000      12       -       -       - r-x--  libtermcap.so.2.0.8 00000035ef603000    2044       -       -       - -----  libtermcap.so.2.0.8 00000035ef802000       4       -       -       - rw---  libtermcap.so.2.0.8 00002aaaaaaab000       4       -       -       - rw---    [ anon ] 00002aaaaaaba000      12       -       -       - rw---    [ anon ] 00002aaaaaabd000      40       -       -       - r-x--  libnss_files-2.5.so 00002aaaaaac7000    2044       -       -       - -----  libnss_files-2.5.so 00002aaaaacc6000       4       -       -       - r----  libnss_files-2.5.so 00002aaaaacc7000       4       -       -       - rw---  libnss_files-2.5.so 00002aaaaacc8000   55112       -       -       - r----  locale-archive 00002aaaae29a000      28       -       -       - r--s-  gconv-modules.cache 00002aaaae2a1000       8       -       -       - rw---    [ anon ] 00007fff9bff4000      92       -       -       - rw---    [ stack ] ffffffffff600000    8192       -       -       - -----    [ anon ] ----------------  ------  ------  ------  ------ total kB           74496       -       -       -

Good way to release product to customer.

http://stackoverflow.com/questions/2264565/debugging-in-linux-using-core-dumps

It sounds like there are other differences between your release and debug build then simply the absence/presence of the -g flag. Assuming that's the case, there is nothing you can do right now, but you can adjust your build to handle this better:

Here's what we do at my place of work.

1. Include the -g flag when building the release version.
2. Archive that version.
3. run strip --strip-unneeded on the binary before shipping it to customers.

Now, when we get a crash we can use the archived version with symbols to do debugging.

One thing to note is that if your release version includes optimization, debugging may be difficult even with symbols. For example, the optimizer can reorder your code so even though the debugger will say you crashed on line N, you can't assume that the code actually executed line N-1.

compare binary files

cmp -l file1.bin file2.bin | awk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}'

gvim -d <(xxd -c 1 ~/file1.bin | awk '{print $2, $3}') <(xxd -c 1 ~/file2.bin | awk '{print $2, $3}')