Hi
We are using Oracle as our backend.
One of our job is getting aborted with the following error.
Operator terminated abnormally: received Signal SIGBUS.
Can anybody tell me why following error occurs and how to resolve it?
Is this error related to database?
Thanks
Signal SIGBUS in parallel job
Moderators: chulett, rschirm, roy
SIGBUS is a unix error. It has been discussed here lot of time. Just search the forum with the exact error you got. It is the error thrown out due to Signal bus.
Its most likely due to the resource contention. If you are running multiple jobs parallely, try to run one after other till you idnetify the exact issue.
Its most likely due to the resource contention. If you are running multiple jobs parallely, try to run one after other till you idnetify the exact issue.
Impossible doesn't mean 'it is not possible' actually means... 'NOBODY HAS DONE IT SO FAR'
-
AmeyJoshi14
- Participant
- Posts: 334
- Joined: Fri Dec 01, 2006 5:17 am
- Location: Texas
For the detail information of SIGBUS you can refer to the following link:
http://en.wikipedia.org/wiki/SIGBUS
The extract states the following things:
On POSIX-compliant platforms, SIGBUS is the signal thrown by computer programs causing a bus error. The symbolic constant for SIGBUS is defined in the header file signal.h. Symbolic signal names are used because signal numbers can vary across platforms.
Etymology
SIG is a common prefix for signal names. BUS refers to the data bus in the context of a bus error.
Usage
Computer programs may throw SIGBUS for improper memory handling:
Invalid address alignment
The program has attempted to read or write data that does not fit the CPU's memory-alignment rules.
Non-existent physical address
This is equivalent to a segmentation fault, but for a physical address rather than a virtual address.
Object-specific hardware error
This is far less common, but it is present in Solaris, when virtual memory pages have disappeared (e.g. accessing an mmaped file which has been truncated. [1])
For further discussion, see bus error.
The operating system may inform the application of the nature of the error using the signal stack, which developers can use to debug their programs or handle errors.
The default action for a program upon receiving SIGBUS is abnormal termination. This will end the process, but may generate a core file to aid debugging, or other platform dependent action.
SIGBUS can be handled (caught). That is, applications can request what action they want to occur. Examples of such action might be ignoring it, calling a function, or restoring the default action. In some circumstances, ignoring SIGBUS results in undefined behaviour.
An example of an application that might handle SIGBUS is a debugger, which might check the signal stack and inform the developer of what happened, and where the program terminated.
SIGBUS is usually generated by the operating system, but users with appropriate permissions can use the kill system call or kill command (a userland program, or sometimes a shell builtin) to send the signal to a process at will.
http://en.wikipedia.org/wiki/SIGBUS
The extract states the following things:
On POSIX-compliant platforms, SIGBUS is the signal thrown by computer programs causing a bus error. The symbolic constant for SIGBUS is defined in the header file signal.h. Symbolic signal names are used because signal numbers can vary across platforms.
Etymology
SIG is a common prefix for signal names. BUS refers to the data bus in the context of a bus error.
Usage
Computer programs may throw SIGBUS for improper memory handling:
Invalid address alignment
The program has attempted to read or write data that does not fit the CPU's memory-alignment rules.
Non-existent physical address
This is equivalent to a segmentation fault, but for a physical address rather than a virtual address.
Object-specific hardware error
This is far less common, but it is present in Solaris, when virtual memory pages have disappeared (e.g. accessing an mmaped file which has been truncated. [1])
For further discussion, see bus error.
The operating system may inform the application of the nature of the error using the signal stack, which developers can use to debug their programs or handle errors.
The default action for a program upon receiving SIGBUS is abnormal termination. This will end the process, but may generate a core file to aid debugging, or other platform dependent action.
SIGBUS can be handled (caught). That is, applications can request what action they want to occur. Examples of such action might be ignoring it, calling a function, or restoring the default action. In some circumstances, ignoring SIGBUS results in undefined behaviour.
An example of an application that might handle SIGBUS is a debugger, which might check the signal stack and inform the developer of what happened, and where the program terminated.
SIGBUS is usually generated by the operating system, but users with appropriate permissions can use the kill system call or kill command (a userland program, or sometimes a shell builtin) to send the signal to a process at will.