Home > Articles > Cisco > CCNP Routing and Switching

  • Print
  • + Share This
This chapter is from the book

show stacks Command

show stacks is an exec command that is commonly used to diagnose system crash situations. The first section of this command's output displays stack utilization of processes and interrupt routines, and the reason for the last system reboot. When a system crash happens, failure type, failure program counter (PC), address (operand address), and a stack trace are saved by the ROM Monitor. The show stacks command displays the data saved by the ROM Monitor. The stack trace is displayed in the second section of the show stacks command output (if there has been a system failure).

In the past, support engineers would submit the stack trace of their router to Cisco System's technical support representatives, who had access to symbol tables, object files, source code, and the stack decoder software. Today, the stack decoder is available online (from the CCO) and you can cut your router's stack trace from the output of the show stacks command and paste it in the input field of the stack decoder software. Stack decoder decodes the stack trace and creates a symbol file. The symbol file (perhaps along with other information in the trace) usually provides enough information to isolate the cause of any problems that were experienced.

Example 4-12 shows an example of the show stacks output from a bus error. The message "System was restarted by bus error" indicates that the processor tried to use a device or a memory location that either did not exist or did not respond properly (this could be due to a software bug or a hardware problem). Operand address, the address the processor was trying to access when the system crashed, is used as the clue to tell if the failure was due to software or hardware. If the operand address (reported on the output of the show stacks command) is valid, the problem is probably in the hardware. In other words, the operand address, not the program counter, provides the memory map location of the error, which can be used to infer the general area of the router where the error occurred.

Example 4-12 A Sample Output of the show stacks Command

Router# show stacks


Minimum process stacks:

Free/Size Name

652/1000 Router Init

726/1000 Init

744/1000 BGP Open

686/1200 Virtual Exec

Interrupt Level stacks:

Level Called Free/Size Name

1 0 1000/1000 env-flash

3 738 900/1000 Multiport Communications Interfaces

5 178 970/1000 Console UART

System was restarted by bus error at PC 0xAD1F4, address 0xD0D0D1A

GS Software (GS3), Version 10.2

Compiled Tue 11-Aug-94 13:27 by jthomas

Stack trace from system failure:

FP: 0x29C158, RA: 0xACFD4

FP: 0x29C184, RA: 0xAD20C

FP: 0x29C1B0, RA: 0xACFD4

FP: 0x29C1DC, RA: 0xAD304

FP: 0x29C1F8, RA: 0xAF774

FP: 0x29C214, RA: 0xAF83E

FP: 0x29C228, RA: 0x3E0CA

FP: 0x29C244, RA: 0x3BD3C

Failure types are usually one of the following: bus error, address error, watchdog timeout, parity error, or emulator trap. Table 4-9 displays common failure types with a brief description for each of them.

Table 4-9 Common Failure Types Reported by the show stacks Command

Failure Type


Bus error

The processor tried to use a device or a memory location that either did not exist or did not respond properly (could be due to software bug or hardware error).

Address error

(software forced crash)

The software tried to access data on incorrectly aligned boundaries (usually indicates a software bug).

Watchdog timeout

Watchdog timer was not reset and caused a trap. Watchdog timers are used by Cisco processors to prevent certain system hangs (indicates a hardware or software bug).

Parity error

Internal hardware checks have failed (this is due to hardware problems).

Emulator trap

Processor executed an illegal instruction (illegal branching). A hardware problem, such as ROM failure, can also cause an emulator trap error.

  • + Share This
  • 🔖 Save To Your Account