Document ID: 10782
Updated: Oct 06, 2005
Contents
Introduction
This document explains the software error (swerr) 506, which may occur on IGX or BPX switches.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
The information in this document is based on IGX and BPX switches.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Software Error 506
A swerr 506 is logged from the routine that frees allocated memory. Its presence usually indicates that the process that frees the memory is not the process that owns the memory. After the error is logged, the memory is freed.
The process ID of the owner of the memory is in the data field. This should be some value less than the maximum number of processes (displayed with the dspprf command).
1.Error 506 00000006 3003BF4A PROT 8.1.1j 06/24/96 05:48:411
US 30374AE0 30 03 BF 4A 00 00 01 FA 00 00 00 06 30 1A 58 5E
Process ID Alloc Address
This example indicates that the PROT process is trying to free memory owned by process 6 (probably SNMP). The first line of the detail stack dump shows the process ID (6) and the address of the routine that allocated the memory (301A585E).
This is a valid process ID and a valid memory address for code space. This indicates that the error was logged due to a problem with the way the switch software handled the memory ownership. To try to isolate the problem, you can trace the way the allocated memory was handled from the allocation address to the Free_mem address. If this problem is observed in the field, it is not usually cause for concern.
If the process ID in the data field is not a valid process ID, the allocated memory block may have been corrupted by a memory overwrite. This is a significant problem, as memory overwrites can cause memory corruption. Memory corruption can cause many problems, including 1M3 aborts. See this example:
Active Control Card Software Log
No. Type Number Data(Hex) PC(Hex) PROC SwRev Date Time 1. Error 506 0000FDE2 3003C04C NETW 8.1.18 10/28/96 23:05:27 2. Abort 1000003 00000000 300156A0 NETW 8.1.18 10/28/96 23:05:27
From the detail abort stack:
1. Error 506 0000FDE2 3003C04C NETW 8.1.18 10/28/96 23:05:27 USP 30356568 30 03 C0 4C 00 00 01 FA 00 00 FD E2 00 00 2F 02
This example shows that both the process ID (00 00 01 FA) and the allocation address (00 00 2F 02) have been corrupted. It is very probable that the corruption extends past the header into the data area of the memory block. It is also probable that the next block of memory allocated to this memory location will be corrupted.
The corrupting memory block cannot be determined from the errors logged by this event. A swerr 514, which is logged when the block that is actually exceeded is freed, is required. The network should be checked for swerr 514s that corrupt the entire DEADFACE flag. (Refer to Software Error 514.)
Related Information
Open a Support Case 
(Requires a Cisco Service Contract.)
Related Cisco Support Community Discussions
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.