Issues While Running Debugger

When the dbx debugger is being used on the Solaris 10 OS on x86 platforms to debug a program that raises or delivers signals that have signal handlers, dbx might receive an unexpected SIGTRAP signal from the kernel that causes the debugger to hang. This situation can occur when dbx is single stepping, running to a breakpoint, collecting runtime checking (RTC) data, or performing any other activity that depends on signal trapping.

In some cases, dbx displays a warning of an unexpected SIGTRAP signal when it hangs. For example:

dbx: internal warning: unexpected SIGTRAP!

In other cases, dbx indicates receipt of a SEGV signal. For example:

signal SEGV (no mapping at the fault address) in main at line 29 in file "test.c"

In this case, when the user types the cont -sig SEGV command to continue execution with the SEGV signal, dbx displays the warning of the unexpected SIGTRAP.

This bug is introduced into the Solaris 10 OS on x86 platforms when kernel patch 127112 is installed.

Workaround: Do not install kernel patch 127112. Uninstall the kernel patch if it has already been installed. For more information about this bug, see the Sun Studio Support News page at http://developers.sun.com/sunstudio/support/troubleshooting/index.jsp.

SPARC: Problems With dbx Debugger While Processing 64-bit Objects (6347707)

The dbx debugger terminates with a memory access failure while processing certain 64-bit executable files and libraries. However, the problem does not affect the normal use of these 64-bit objects. An error message similar to the following example is displayed:

dbx: internal error: signal SIGBUS (invalid address alignment)

Workaround: Use either the mdb debugger or the Solaris Dynamic Tracing facility instead. These alternatives can diagnose processes that use the 64-bit objects.

System Might Loop When Master CPU Is Changed (4405263)

A system that is running the Solaris kernel debugger to debug a live system might loop with incomplete error messages. This loop occurs when the OpenBoot PROM's master CPU is changed. A system reset restores the system to operation. However, the traces of the original failure are lost. Consequently, you cannot perform a diagnosis of the fatal reset.

Workaround: When the system is at the PROM level, the OpenBoot's ok prompt is displayed. In a system with multiple CPUs, the ok prompt is preceded by a number that is enclosed in curly braces. This number indicates the active CPU in the system. To run your debug session while at the PROM level, use the following steps.

Raise pil to f by typing the following command:
```
{0} ok h# 0f pil!
```
Use the switch-cpu command to selectively switch from the currently active CPU to different CPUs. For example, to switch from CPU #0 to CPU #1, type the following command:
```
(0) ok 1 switch-cpu
```
The ok prompt is now preceded by the number of the CPU to which you switched.
```
{1} ok
```
Run your debugger.
At the end of your debugger session, issue a reset-all command to return the system to normal use.

Note - Make sure that you upgrade the system to the latest version of the OpenBoot PROM.

Skip Navigation Links
Exit Print View
	Solaris 10 5/08 Release Notes