Most recent kernel where this bug did not occur: Distribution: Hardware Environment: Software Environment: Problem Description: The Linux kernel ACPI interpreter fails the following AML test when it is compiled into a simulator. So if an OEM BIOS includes this code, Linux would fail. Steps to reproduce: Run interpreter with the .asl demo code attached below.
Created attachment 7271 [details] ASL code to reproduce bug. 'Error #' message reports bug.
Created attachment 7272 [details] Proposed patch The bug appeared as an unpredictable behaviour of AML interpretation after some exceptions in "32-bit slack mode". ROOT CAUSE: For some unsuccessfully completed operations the ResultObj object nevertheless had been initialized with the pointer to the internal object as if ResultObj referred the valid object; moreover, just after that, the object referred by the pointer was damaged by AcpiUtRemoveReference(). INTERNAL BUG NUMBER: 198 FIXED: No value is assigned to ResultObj when operation failed. TESTED: The update was tested by the ASLTS test suite runs (all the test cases) on the following systems: - CYGWIN_NT-5.1 1.5.18(0.132/4/2) 2005-07-02 20:30 i686 unknown unknown Cygwin - Linux 2.6.5-7.191-smp #1 SMP Tue Jun 28 14:58:56 UTC 2005 i686 i686 i386 GNU/Linux for the following (all) modes supported by the ASLTS test suite: - 32-bit norm mode - 64-bit norm mode - 32-bit slack mode - 64-bit slack mode The tests were run (on the systems described above) before update, then the tests were run on those systems after update. Then results of two runs were compared. All is Ok (the relevant error fixed, no new errors).
I think that the philosophy (through most of the ACPICA code) is that if an exception is returned, the return value is undefined; Perhaps the real problem is that a caller is assuming that the return value is NULL in the error case?
Patch integrated into version 20060310
ACPICA 20060608 shipped in Linux-2.6.17-git9, closed.