Often we come into situation where the existing db2 license got expired and we cannot able to start the instance and running into below error
bash-3.2$ db2start
08/05/2010 23:31:34 0 0 SQL8000N DB2START processing failed; a valid product license was not found. If you have licensed this product, ensure the license key is properly registered. You can register the license via the License Center or db2licm command line utility. The license key can be obtained from your licensed product CD.
SQL1032N No start database manager command was issued. SQLSTATE=57019
To resolve the above error, you can see when the expired date for license with below command
bash-3.2$ db2licm -l
Product name: "DB2 Enterprise Server Edition"
Expiry date: "Expired"
Product identifier: "db2ese"
Version information: "9.5"
Product name: "DB2 Connect Server"
Expiry date: "Expired"
Product identifier: "db2consv"
Version information: "9.5"
Concurrent connect user policy: "Disabled"
Enforcement policy: "Soft Stop"
You have to remove the license and apply the license to start the db2 instance. Below are the swiches you can use with db2licm
======
db2licm [-a filename]
[-e product-identifier HARD | SOFT]
[-p product-identifier
CONCURRENT | OFF]
[-r product-identifier]
[-u product-identifier num-users]
[-c product-identifier num-connectors]
[-g filename]
[-x]
[-l][show detail]
[-v]
[-?]
The command options are:
-a Adds a license for a product. Specify a file name containing
valid license information. This can be obtained from your
licensed product CD or contact your IBM representative or
authorized dealer.
-e Updates the enforcement policy on the system. Valid values are:
HARD and SOFT. HARD specifies that unlicensed requests will not
be allowed. SOFT specifies that unlicensed requests will be
logged but not restricted.
-p Updates the license policy type to use on the system. The
keyword CONCURRENT can be specified for concurrent user policy.
Specify OFF to turn off all policies.
-r Removes the license for a product. Specify the product
identifier.
-u Updates the number of user entitlements that have been
purchased. Specify the product identifier and the number of
users.
-c Updates the number of connector entitlements that have been
purchased. Specify the product identifier and the number of
connector entitlements.
-g Generates compliance report. Specify file name where output is
to be stored.
-x Resets license compliance information for the purposes of
license compliance report.
-l[show detail]
Lists all the products with available license information,
including the product identifier. Specify [show detail] to view
detailed information about licensed features (if any).
-v Displays version information.
-? Displays help information. When this option is specified, all
other options are ignored, and only the help information is
displayed.
=====
To remove db2 license
bash-3.2$ db2licm -r "db2ese"
LIC1403I License removed successfully.
=====
To apply db2 license
bash-3.2$ db2licm -a "/data1/db2/databases/v95inst1/db2ese.lic"
LIC1448I This license was automatically applied at install time in
order to enable you to start working with DB2
Thursday, August 5, 2010
Tuesday, August 3, 2010
Finding out Oracle Execution plan plus how much time the query take to complete
SQL> conn system/admin as sysdba
Connected.
SQL> SET AUTOTRACE ON
SQL> select * from scott.emp;
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
- --------- ---------- --------- ---------- ---------- ----------
7369 SMITH CLERK 7902 17-DEC-80 800 20
7499 ALLEN SALESMAN 7698 20-FEB-81 1600 300 30
7521 WARD SALESMAN 7698 22-FEB-81 1250 500 30
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
---------- --------- ---------- --------- ---------- ---------- ----------
7566 JONES MANAGER 7839 02-APR-81 2975 20
7654 MARTIN SALESMAN 7698 28-SEP-81 1250 1400 30
7698 BLAKE MANAGER 7839 01-MAY-81 2850 30
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7782 CLARK MANAGER 7839 09-JUN-81 2450
10
7788 SCOTT ANALYST 7566 19-APR-87 3000
20
7839 KING PRESIDENT 17-NOV-81 5000
10
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7844 TURNER SALESMAN 7698 08-SEP-81 1500 0
30
7876 ADAMS CLERK 7788 23-MAY-87 1100
20
7900 JAMES CLERK 7698 03-DEC-81 950
30
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7902 FORD ANALYST 7566 03-DEC-81 3000
20
7934 MILLER CLERK 7782 23-JAN-82 1300
10
14 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 3956160932
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 14 | 518 | 3 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| EMP | 14 | 518 | 3 (0)| 00:00:01 |--------------------------------------------------------------------------
Statistics
----------------------------------------------------------
340 recursive calls
0 db block gets
69 consistent gets
0 physical reads
0 redo size
1415 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
14 rows processed
==============
To get how much time the query takes to complete, one can follow the below approach
SQL> spool timing.log
SQL> select * from scott.emp;
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7369 SMITH CLERK 7902 17-DEC-80 800
20
7499 ALLEN SALESMAN 7698 20-FEB-81 1600 300
30
7521 WARD SALESMAN 7698 22-FEB-81 1250 500
30
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7566 JONES MANAGER 7839 02-APR-81 2975
20
7654 MARTIN SALESMAN 7698 28-SEP-81 1250 1400
30
7698 BLAKE MANAGER 7839 01-MAY-81 2850
30
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7782 CLARK MANAGER 7839 09-JUN-81 2450
10
7788 SCOTT ANALYST 7566 19-APR-87 3000
20
7839 KING PRESIDENT 17-NOV-81 5000
10
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7844 TURNER SALESMAN 7698 08-SEP-81 1500 0
30
7876 ADAMS CLERK 7788 23-MAY-87 1100
20
7900 JAMES CLERK 7698 03-DEC-81 950
30
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7902 FORD ANALYST 7566 03-DEC-81 3000
20
7934 MILLER CLERK 7782 23-JAN-82 1300
10
14 rows selected.
SQL> cle scr
SQL> spool display.log
SQL> SET TIMING ON
SQL> select * from scott.emp;
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7369 SMITH CLERK 7902 17-DEC-80 800
20
7499 ALLEN SALESMAN 7698 20-FEB-81 1600 300
30
7521 WARD SALESMAN 7698 22-FEB-81 1250 500
30
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7566 JONES MANAGER 7839 02-APR-81 2975
20
7654 MARTIN SALESMAN 7698 28-SEP-81 1250 1400
30
7698 BLAKE MANAGER 7839 01-MAY-81 2850
30
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7782 CLARK MANAGER 7839 09-JUN-81 2450
10
7788 SCOTT ANALYST 7566 19-APR-87 3000
20
7839 KING PRESIDENT 17-NOV-81 5000
10
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7844 TURNER SALESMAN 7698 08-SEP-81 1500 0
30
7876 ADAMS CLERK 7788 23-MAY-87 1100
20
7900 JAMES CLERK 7698 03-DEC-81 950
30
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7902 FORD ANALYST 7566 03-DEC-81 3000
20
7934 MILLER CLERK 7782 23-JAN-82 1300
10
14 rows selected.
Elapsed: 00:00:00.00
SQL> spool off
Connected.
SQL> SET AUTOTRACE ON
SQL> select * from scott.emp;
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
- --------- ---------- --------- ---------- ---------- ----------
7369 SMITH CLERK 7902 17-DEC-80 800 20
7499 ALLEN SALESMAN 7698 20-FEB-81 1600 300 30
7521 WARD SALESMAN 7698 22-FEB-81 1250 500 30
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
---------- --------- ---------- --------- ---------- ---------- ----------
7566 JONES MANAGER 7839 02-APR-81 2975 20
7654 MARTIN SALESMAN 7698 28-SEP-81 1250 1400 30
7698 BLAKE MANAGER 7839 01-MAY-81 2850 30
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7782 CLARK MANAGER 7839 09-JUN-81 2450
10
7788 SCOTT ANALYST 7566 19-APR-87 3000
20
7839 KING PRESIDENT 17-NOV-81 5000
10
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7844 TURNER SALESMAN 7698 08-SEP-81 1500 0
30
7876 ADAMS CLERK 7788 23-MAY-87 1100
20
7900 JAMES CLERK 7698 03-DEC-81 950
30
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7902 FORD ANALYST 7566 03-DEC-81 3000
20
7934 MILLER CLERK 7782 23-JAN-82 1300
10
14 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 3956160932
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 14 | 518 | 3 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| EMP | 14 | 518 | 3 (0)| 00:00:01 |--------------------------------------------------------------------------
Statistics
----------------------------------------------------------
340 recursive calls
0 db block gets
69 consistent gets
0 physical reads
0 redo size
1415 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
14 rows processed
==============
To get how much time the query takes to complete, one can follow the below approach
SQL> spool timing.log
SQL> select * from scott.emp;
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7369 SMITH CLERK 7902 17-DEC-80 800
20
7499 ALLEN SALESMAN 7698 20-FEB-81 1600 300
30
7521 WARD SALESMAN 7698 22-FEB-81 1250 500
30
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7566 JONES MANAGER 7839 02-APR-81 2975
20
7654 MARTIN SALESMAN 7698 28-SEP-81 1250 1400
30
7698 BLAKE MANAGER 7839 01-MAY-81 2850
30
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7782 CLARK MANAGER 7839 09-JUN-81 2450
10
7788 SCOTT ANALYST 7566 19-APR-87 3000
20
7839 KING PRESIDENT 17-NOV-81 5000
10
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7844 TURNER SALESMAN 7698 08-SEP-81 1500 0
30
7876 ADAMS CLERK 7788 23-MAY-87 1100
20
7900 JAMES CLERK 7698 03-DEC-81 950
30
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7902 FORD ANALYST 7566 03-DEC-81 3000
20
7934 MILLER CLERK 7782 23-JAN-82 1300
10
14 rows selected.
SQL> cle scr
SQL> spool display.log
SQL> SET TIMING ON
SQL> select * from scott.emp;
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7369 SMITH CLERK 7902 17-DEC-80 800
20
7499 ALLEN SALESMAN 7698 20-FEB-81 1600 300
30
7521 WARD SALESMAN 7698 22-FEB-81 1250 500
30
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7566 JONES MANAGER 7839 02-APR-81 2975
20
7654 MARTIN SALESMAN 7698 28-SEP-81 1250 1400
30
7698 BLAKE MANAGER 7839 01-MAY-81 2850
30
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7782 CLARK MANAGER 7839 09-JUN-81 2450
10
7788 SCOTT ANALYST 7566 19-APR-87 3000
20
7839 KING PRESIDENT 17-NOV-81 5000
10
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7844 TURNER SALESMAN 7698 08-SEP-81 1500 0
30
7876 ADAMS CLERK 7788 23-MAY-87 1100
20
7900 JAMES CLERK 7698 03-DEC-81 950
30
EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- --------- ---------- ----------
DEPTNO
----------
7902 FORD ANALYST 7566 03-DEC-81 3000
20
7934 MILLER CLERK 7782 23-JAN-82 1300
10
14 rows selected.
Elapsed: 00:00:00.00
SQL> spool off
Monday, June 14, 2010
Checking the Space in Tablespace
Hello Everyone,
Many times we runs into issues where the tablespace has not enabled the autoextend feature and it runs out of space. One can use below script to check, what is the tablespace size and how much free space available
SQL> SELECT Total.name "Tablespace Name",
2 nvl(Free_space, 0) Free_space,
3 nvl(total_space-Free_space, 0) Used_space,
4 total_space
5 FROM
6 (select tablespace_name, sum(bytes/1024/1024) Free_Space
7 from sys.dba_free_space
8 group by tablespace_name
9 ) Free,
10 (select b.name, sum(bytes/1024/1024) TOTAL_SPACE
11 from sys.v_$datafile a, sys.v_$tablespace B
12 where a.ts# = b.ts#
13 group by b.name
14 ) Total
15 WHERE Free.Tablespace_name(+) = Total.name
16 ORDER BY Total.name
17 /
Tablespace Name FREE_SPACE USED_SPACE TOTAL_SPACE
------------------------------ ---------- ---------- -----------
ARSYSTEMMONTRE 240.5 59.5 300
ARSYSTEMV 1868.625 131.375 2000
ARSYSTEMVIGNESH 244.0625 55.9375 300
ARUNDOTBS 8.6875 1.3125 10
ATRIUMWS 458.8125 41.1875 500
SYSAUX 17.8125 362.1875 380
SYSTEM 3.3125 586.6875 590
UNDOTBS1 981.375 18.625 1000
USERS 4.5625 .4375 5
9 rows selected.
Happy Learning!!
Vaibhav
Many times we runs into issues where the tablespace has not enabled the autoextend feature and it runs out of space. One can use below script to check, what is the tablespace size and how much free space available
SQL> SELECT Total.name "Tablespace Name",
2 nvl(Free_space, 0) Free_space,
3 nvl(total_space-Free_space, 0) Used_space,
4 total_space
5 FROM
6 (select tablespace_name, sum(bytes/1024/1024) Free_Space
7 from sys.dba_free_space
8 group by tablespace_name
9 ) Free,
10 (select b.name, sum(bytes/1024/1024) TOTAL_SPACE
11 from sys.v_$datafile a, sys.v_$tablespace B
12 where a.ts# = b.ts#
13 group by b.name
14 ) Total
15 WHERE Free.Tablespace_name(+) = Total.name
16 ORDER BY Total.name
17 /
Tablespace Name FREE_SPACE USED_SPACE TOTAL_SPACE
------------------------------ ---------- ---------- -----------
ARSYSTEMMONTRE 240.5 59.5 300
ARSYSTEMV 1868.625 131.375 2000
ARSYSTEMVIGNESH 244.0625 55.9375 300
ARUNDOTBS 8.6875 1.3125 10
ATRIUMWS 458.8125 41.1875 500
SYSAUX 17.8125 362.1875 380
SYSTEM 3.3125 586.6875 590
UNDOTBS1 981.375 18.625 1000
USERS 4.5625 .4375 5
9 rows selected.
Happy Learning!!
Vaibhav
Wednesday, February 17, 2010
GDB Debugger Install Steps
It is now possible to automatically configure and build a variety of
tools with one command. To build all of the tools contained herein,
run the ``configure'' script here, e.g.:
./configure
make
To install them (by default in /usr/local/bin, /usr/local/lib, etc),
then do:
make install
(If the configure script can't determine your type of computer, give it
the name as an argument, for instance ``./configure sun4''. You can
use the script ``config.sub'' to test whether a name is recognized; if
it is, config.sub translates it to a triplet specifying CPU, vendor,
and OS.)
If you have more than one compiler on your system, it is often best to
explicitly set CC in the environment before running configure, and to
also set CC when running make. For example (assuming sh/bash/ksh):
CC=gcc ./configure
make
README for GNU development tools
This directory contains various GNU compilers, assemblers, linkers,
debuggers, etc., plus their support routines, definitions, and documentation.
If you are receiving this as part of a GDB release, see the file gdb/README.
If with a binutils release, see binutils/README; if with a libg++ release,
see libg++/README, etc. That'll give you info about this
package -- supported targets, how to use it, how to report bugs, etc.
It is now possible to automatically configure and build a variety of
tools with one command. To build all of the tools contained herein,
run the ``configure'' script here, e.g.:
./configure
make
To install them (by default in /usr/local/bin, /usr/local/lib, etc),
then do:
make install
(If the configure script can't determine your type of computer, give it
the name as an argument, for instance ``./configure sun4''. You can
use the script ``config.sub'' to test whether a name is recognized; if
it is, config.sub translates it to a triplet specifying CPU, vendor,
and OS.)
If you have more than one compiler on your system, it is often best to
explicitly set CC in the environment before running configure, and to
also set CC when running make. For example (assuming sh/bash/ksh):
CC=gcc ./configure
make
A similar example using csh:
setenv CC gcc
./configure
make
Much of the code and documentation enclosed is copyright by
the Free Software Foundation, Inc. See the file COPYING or
COPYING.LIB in the various directories, for a description of the
GNU General Public License terms under which you can copy the files.
REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info
tools with one command. To build all of the tools contained herein,
run the ``configure'' script here, e.g.:
./configure
make
To install them (by default in /usr/local/bin, /usr/local/lib, etc),
then do:
make install
(If the configure script can't determine your type of computer, give it
the name as an argument, for instance ``./configure sun4''. You can
use the script ``config.sub'' to test whether a name is recognized; if
it is, config.sub translates it to a triplet specifying CPU, vendor,
and OS.)
If you have more than one compiler on your system, it is often best to
explicitly set CC in the environment before running configure, and to
also set CC when running make. For example (assuming sh/bash/ksh):
CC=gcc ./configure
make
README for GNU development tools
This directory contains various GNU compilers, assemblers, linkers,
debuggers, etc., plus their support routines, definitions, and documentation.
If you are receiving this as part of a GDB release, see the file gdb/README.
If with a binutils release, see binutils/README; if with a libg++ release,
see libg++/README, etc. That'll give you info about this
package -- supported targets, how to use it, how to report bugs, etc.
It is now possible to automatically configure and build a variety of
tools with one command. To build all of the tools contained herein,
run the ``configure'' script here, e.g.:
./configure
make
To install them (by default in /usr/local/bin, /usr/local/lib, etc),
then do:
make install
(If the configure script can't determine your type of computer, give it
the name as an argument, for instance ``./configure sun4''. You can
use the script ``config.sub'' to test whether a name is recognized; if
it is, config.sub translates it to a triplet specifying CPU, vendor,
and OS.)
If you have more than one compiler on your system, it is often best to
explicitly set CC in the environment before running configure, and to
also set CC when running make. For example (assuming sh/bash/ksh):
CC=gcc ./configure
make
A similar example using csh:
setenv CC gcc
./configure
make
Much of the code and documentation enclosed is copyright by
the Free Software Foundation, Inc. See the file COPYING or
COPYING.LIB in the various directories, for a description of the
GNU General Public License terms under which you can copy the files.
REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info
Resetting Sys/system password for oracle databases
Doc ID: NOTE:114384.1
/oracle/product/10.2.0/dbs
bash-2.05$ cp orapworcl orapworcl.bak
bash-2.05$ orapwd file=orapworcl password=admin entries=30 force=y
/oracle/product/10.2.0/dbs
bash-2.05$ cp orapworcl orapworcl.bak
bash-2.05$ orapwd file=orapworcl password=admin entries=30 force=y
A lesson in UNIX memory
When a process on UNIX needs memory, it is malloc’d. The process will grow in size. When the process is finished using that memory it will free the memory. This free memory is added to a free list for the running process. The footprint (size) of the process remains the same and does not decrease. This is a design in UNIX memory managers. Note that Windows servers will cause the memory footprint to decrease. On UNIX, the process now may require memory again. UNIX will use up the memory from the free list and the process will not grow. If the process does not have a segment of memory that is large enough for the new malloc, it will require more memory from the OS and the footprint will grow. When the memory is no longer needed, a free will return that memory to the free list within the process, but the process does not decrease. The OS vendor may have information on memory malloc and free or memory fragmentation that may help explain it.
For More information
http://developers.sun.com/solaris/articles/solaris_memory.html
For More information
http://developers.sun.com/solaris/articles/solaris_memory.html
Saturday, October 31, 2009
Debugging A Running Process with GDB Debugger
So far, we've debugged executables, with and without core files. However, we can debug processes too. Think about that -- we can debug a process that has already been started outside the debugger. There are two ways of doing this: Using command line arguments and using the attach command.
Download and read beer-process.c and its Makefile. Compile it, and run it as a background job in one console (or xterm). It'll simply print out the number of bottles of beer on the wall:
$ ./beer-process &
[1] 17399
p@satan$ 100000 bottles of beer on the wall.
99999 bottles of beer on the wall.
99998 bottles of beer on the wall.
99997 bottles of beer on the wall.
With Command Line Arguments
With the beer process running one console, start GDB in another console with an argument list of the executable and the process ID. The process ID should've been printed when you started the background process:
$ gdb beer-process 17399
Attaching to program: code/running_process/beer-process, process 17399
0x410c64fb in nanosleep () from /lib/tls/libc.so.6
(gdb)
Chances are overwhelmingly good that the process is in GoToSleep(). Print out a backtrace and take a look at the stack:
(gdb) bt
#0 0x410c64fb in nanosleep () from /lib/tls/libc.so.6
#1 0x410c6358 in sleep () from /lib/tls/libc.so.6
#2 0x0804841f in GoToSleep () at beer-process.c:32
#3 0x080483e0 in main () at beer-process.c:14
Aside: Note that GoToSleep() calls the C library function sleep(), and sleep(), in turn, calls the system call nanosleep(). As you know, all library functions (glibc on Linux) do their job by calling system calls. I'm a little surprised to see the library and system functions listed in the call stack since I'm not using a debugging version of glibc. Weird.
At this point, the backtrace should be very familiar to you. But there's an important distinction. We didn't run this program from within GDB. We ran it from the command line, and then had GDB attach to an already running process.
Look at the output of the beer process: you should notice that the process has stopped! Whenever GDB attaches to a running process, the process is paused so you can get a handle on what the call stack looks like. Let's do some interesting things.
In my output above, i=9997. Yours is probably different, but nevertheless, you should be able to follow along with me. Let's verify the value of i by selecting the stack frame for main() and looking at its value:
(gdb) frame 3
#3 0x080483eb in main () at beer-process.c:15
15 GoToSleep();
(gdb) print i
$1 = 99997
No surprises here. As you'd expect, we can use next and step (which takes us out of nanosleep() and sleep() respectively, putting us into GoToSleep()):
(gdb) next
Single stepping until exit from function nanosleep,
which has no line number information.
0x410c6358 in sleep () from /lib/tls/libc.so.6
(gdb) step
Single stepping until exit from function sleep,
which has no line number information.
GoToSleep () at beer-process.c:34
34 }
(gdb) bt
#0 GoToSleep () at beer-process.c:34
#1 0x080483eb in main () at beer-process.c:15
Looking at the code, the next things to happen are that i will be decremented and then PrintMessage() will print 99996 bottles of beer on the wall. However, suppose we wanted more beer? Let's change to the stack frame for main() (where i lives) and change the number of beers on the wall.
(gdb) frame 3
#3 0x080483eb in main () at beer-process.c:15
15 GoToSleep();
(gdb) set var i = 99999999
Now quit GDB. When GDB detaches from the process, the process will continue along its merry way. We could also use the detach command to detach from the process without quiting GDB; I'll explain detach in the next session.
(gdb) quit
The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from program: code/running_process/beer-process,
process 17399
but with the new value for i:
$ ./beer-process &
[1] 17399
p@satan$ 100000 bottles of beer on the wall.
99999 bottles of beer on the wall.
99998 bottles of beer on the wall.
99997 bottles of beer on the wall.
99999998 bottles of beer on the wall.
99999997 bottles of beer on the wall.
99999996 bottles of beer on the wall.
99999995 bottles of beer on the wall.
99999994 bottles of beer on the wall.
I hope you're impressed by this! We attached GDB to a process that was already running. The process halted and we were able to do everything that we would've been able to do had we started the process from within GDB. Now that's power!
One non-debugging use I've had for this in the past is with scientific programming. I had PDE solvers and Monte Carlo applications that would run for a very long time. Whenever I wanted to take a look at how my simulation was doing or what some of the intermediary answers looked like, I'd attach to the process using GDB and inspect my variables. This was a much better option than simply printing everything of interest out, which could've possibly have taken hundreds of megs of disk space!
With The Attach Command
We can also debug an already running process using GDB's attach command to attach to a running process. Again, once attached, we can use the detach command to detach from the process.
If you quit the running background process from the previous section, restart beer-process in the background. Start GDB with no command line arguments. But use the attach command to attach to the running process.
$ gdb
(gdb) attach 17399
Attaching to process 17399
Reading symbols from code/running_process/beer-process...done.
0x410c64fb in nanosleep () from /lib/tls/libc.so.6
(gdb)
As before, the process should halt. This is when you do whatever it is you want to do with the process: debug, snoop, spy, modify, etc. When you're done futzing around, quit GDB:
The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from program: code/running_process/beer-process,
process 17399
As before, once you detach from the process, it'll continue running.
Processes Without Debugging Symbols
As with debugging executables and corefiles, it's only convenient to debug processes that were started from executables with debugging information compiled into them. To see this in action, strip the executable and run it in the background again:
$ strip beer-process
$ ./beer-process &
[1] 32262
p@satan$ 100000 bottles of beer on the wall.
99999 bottles of beer on the wall.
99998 bottles of beer on the wall.
Debug the process and look at the call stack:
$ gdb
(gdb) attach 32262
Attaching to process 32262
Reading symbols from code/running_process/beer-process...(no debugging symbols found)...done.
(gdb) bt
#0 0x410c64fb in nanosleep () from /lib/tls/libc.so.6
#1 0x410c6358 in sleep () from /lib/tls/libc.so.6
#2 0x0804841f in ?? ()
#3 0x00000003 in ?? ()
#4 0x0001869d in ?? ()
#5 0xbffff7b8 in ?? ()
#6 0x080483eb in ?? ()
#7 0x0001869d in ?? ()
#8 0x0001869d in ?? ()
#9 0xbffff844 in ?? ()
#10 0x4102e7f8 in __libc_start_main () from /lib/tls/libc.so.6
#11 0x41150fcc in ?? () from /lib/tls/libc.so.6
Download and read beer-process.c and its Makefile. Compile it, and run it as a background job in one console (or xterm). It'll simply print out the number of bottles of beer on the wall:
$ ./beer-process &
[1] 17399
p@satan$ 100000 bottles of beer on the wall.
99999 bottles of beer on the wall.
99998 bottles of beer on the wall.
99997 bottles of beer on the wall.
With Command Line Arguments
With the beer process running one console, start GDB in another console with an argument list of the executable and the process ID. The process ID should've been printed when you started the background process:
$ gdb beer-process 17399
Attaching to program: code/running_process/beer-process, process 17399
0x410c64fb in nanosleep () from /lib/tls/libc.so.6
(gdb)
Chances are overwhelmingly good that the process is in GoToSleep(). Print out a backtrace and take a look at the stack:
(gdb) bt
#0 0x410c64fb in nanosleep () from /lib/tls/libc.so.6
#1 0x410c6358 in sleep () from /lib/tls/libc.so.6
#2 0x0804841f in GoToSleep () at beer-process.c:32
#3 0x080483e0 in main () at beer-process.c:14
Aside: Note that GoToSleep() calls the C library function sleep(), and sleep(), in turn, calls the system call nanosleep(). As you know, all library functions (glibc on Linux) do their job by calling system calls. I'm a little surprised to see the library and system functions listed in the call stack since I'm not using a debugging version of glibc. Weird.
At this point, the backtrace should be very familiar to you. But there's an important distinction. We didn't run this program from within GDB. We ran it from the command line, and then had GDB attach to an already running process.
Look at the output of the beer process: you should notice that the process has stopped! Whenever GDB attaches to a running process, the process is paused so you can get a handle on what the call stack looks like. Let's do some interesting things.
In my output above, i=9997. Yours is probably different, but nevertheless, you should be able to follow along with me. Let's verify the value of i by selecting the stack frame for main() and looking at its value:
(gdb) frame 3
#3 0x080483eb in main () at beer-process.c:15
15 GoToSleep();
(gdb) print i
$1 = 99997
No surprises here. As you'd expect, we can use next and step (which takes us out of nanosleep() and sleep() respectively, putting us into GoToSleep()):
(gdb) next
Single stepping until exit from function nanosleep,
which has no line number information.
0x410c6358 in sleep () from /lib/tls/libc.so.6
(gdb) step
Single stepping until exit from function sleep,
which has no line number information.
GoToSleep () at beer-process.c:34
34 }
(gdb) bt
#0 GoToSleep () at beer-process.c:34
#1 0x080483eb in main () at beer-process.c:15
Looking at the code, the next things to happen are that i will be decremented and then PrintMessage() will print 99996 bottles of beer on the wall. However, suppose we wanted more beer? Let's change to the stack frame for main() (where i lives) and change the number of beers on the wall.
(gdb) frame 3
#3 0x080483eb in main () at beer-process.c:15
15 GoToSleep();
(gdb) set var i = 99999999
Now quit GDB. When GDB detaches from the process, the process will continue along its merry way. We could also use the detach command to detach from the process without quiting GDB; I'll explain detach in the next session.
(gdb) quit
The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from program: code/running_process/beer-process,
process 17399
but with the new value for i:
$ ./beer-process &
[1] 17399
p@satan$ 100000 bottles of beer on the wall.
99999 bottles of beer on the wall.
99998 bottles of beer on the wall.
99997 bottles of beer on the wall.
99999998 bottles of beer on the wall.
99999997 bottles of beer on the wall.
99999996 bottles of beer on the wall.
99999995 bottles of beer on the wall.
99999994 bottles of beer on the wall.
I hope you're impressed by this! We attached GDB to a process that was already running. The process halted and we were able to do everything that we would've been able to do had we started the process from within GDB. Now that's power!
One non-debugging use I've had for this in the past is with scientific programming. I had PDE solvers and Monte Carlo applications that would run for a very long time. Whenever I wanted to take a look at how my simulation was doing or what some of the intermediary answers looked like, I'd attach to the process using GDB and inspect my variables. This was a much better option than simply printing everything of interest out, which could've possibly have taken hundreds of megs of disk space!
With The Attach Command
We can also debug an already running process using GDB's attach command to attach to a running process. Again, once attached, we can use the detach command to detach from the process.
If you quit the running background process from the previous section, restart beer-process in the background. Start GDB with no command line arguments. But use the attach command to attach to the running process.
$ gdb
(gdb) attach 17399
Attaching to process 17399
Reading symbols from code/running_process/beer-process...done.
0x410c64fb in nanosleep () from /lib/tls/libc.so.6
(gdb)
As before, the process should halt. This is when you do whatever it is you want to do with the process: debug, snoop, spy, modify, etc. When you're done futzing around, quit GDB:
The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from program: code/running_process/beer-process,
process 17399
As before, once you detach from the process, it'll continue running.
Processes Without Debugging Symbols
As with debugging executables and corefiles, it's only convenient to debug processes that were started from executables with debugging information compiled into them. To see this in action, strip the executable and run it in the background again:
$ strip beer-process
$ ./beer-process &
[1] 32262
p@satan$ 100000 bottles of beer on the wall.
99999 bottles of beer on the wall.
99998 bottles of beer on the wall.
Debug the process and look at the call stack:
$ gdb
(gdb) attach 32262
Attaching to process 32262
Reading symbols from code/running_process/beer-process...(no debugging symbols found)...done.
(gdb) bt
#0 0x410c64fb in nanosleep () from /lib/tls/libc.so.6
#1 0x410c6358 in sleep () from /lib/tls/libc.so.6
#2 0x0804841f in ?? ()
#3 0x00000003 in ?? ()
#4 0x0001869d in ?? ()
#5 0xbffff7b8 in ?? ()
#6 0x080483eb in ?? ()
#7 0x0001869d in ?? ()
#8 0x0001869d in ?? ()
#9 0xbffff844 in ?? ()
#10 0x4102e7f8 in __libc_start_main () from /lib/tls/libc.so.6
#11 0x41150fcc in ?? () from /lib/tls/libc.so.6
Subscribe to:
Posts (Atom)