current process (0x%x) infected with %d
This error may be caused by a hardware problem.
Adaptive Server reports this error when it detects a UNIX
signal that specifies an error. The values (“%d”) that display in
this error message vary by platform and Adaptive Server Enterprise versions;
the most common values are 10 and 11.
A value of 10 [SIGBUS] means that the operating system detected an address alignment error or a miscellaneous hardware error (for example, bus timeout).
A timeout can occur when the CPU issues a request across the bus for the contents of a memory location, and that request is not answered within that CPU’s timeout period (usually a few nanoseconds).
A value of 11 [SIGSEGV] means that the operating system detected a segment violation error.
Sometimes this error occurs in conjunction with a stack
overflow or data corruption. For more information on stack overflow,
refer to the error write-up “Stack guardword corrupted”.
The error message appears in the Adaptive Server error log
followed by a stack trace. The “SQL
causing error” or the <lasterror> that displays in
the Adaptive Server error log may be the underlying cause for this
error. But the message can also be just the last data Adaptive Server
had in its cache space.
To identify the <lasterror> (except in the cases where the <lasterror> is 0), get the number that Adaptive Server displays by in the <lasterror> field from the Adaptive Server error log and consult this manual for more information on the error number.
In the following example, the value for <lasterror> is 614.
00: 94/02/14 11:32:26.02 kernel: current process (0x1fb001d) infected with 11 00: 94/02/14 11:32:26.07 kernel: Address 0x808a6ef (closetable+0x2f7), siginfo (code, address) = (2, 0x30) 00: 94/02/14 11:32:26.07 kernel: ************************************ 00: 94/02/14 11:32:26.07 kernel: “SQL causing error” : CREATE TRIGGER 00: 94/02/14 11:32:26.07 kernel: curdb = 22 pstat = 0x10018 “lasterror = 614”
Try to eliminate the <lasterror>, which may be one of the causes for this error (except when <lasterror> is 0).
Rerun the command referenced by the SQL
causing error to see if the problem reoccurs.
If the process is infected with 11 and you can reproduce the problem, correct it as follows:
If
the SQL causing error is
a compiled object such as a stored procedure, trigger, or view,
drop and recreate the object.
If the SQL causing error is
ad hoc rather than a compiled object, moving the data may fix the
problem. Use one of these options:
Select the table data into a new table, drop the old table, and rename the new table to the old table name;
or
Bulk copy the affected table out, drop and re-create the table, and bulk copy back in. This is the most efficient solution for a large table.
If moving the data corrects the problem, the data may
have been corrupt. Be aware that moving corrupted data can lead
to a data loss.
Check your hardware error log as this error can be caused by hardware failure as well.
If this error persists, contact Sybase Technical Support. It would be useful to have a reproduction case (for example, a query that always causes the “infected” message) before calling Technical Support.
Before calling Technical Support for assistance, have the information hand that is listed in “Reporting errors”.
