Bug 5326 - Crash while processing the global level execution exception
Summary: Crash while processing the global level execution exception
Status: CLOSED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: ACPICA-Core (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Valery A Podrezov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-09-29 04:58 UTC by Valery A Podrezov
Modified: 2006-09-28 13:20 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
ASL code to reproduce bug (509 bytes, text/plain)
2005-09-29 05:00 UTC, Valery A Podrezov
Details
proposed patch (1.84 KB, patch)
2005-09-29 05:02 UTC, Valery A Podrezov
Details | Diff
The attached test run output (1.80 KB, text/plain)
2005-09-29 05:16 UTC, Valery A Podrezov
Details

Description Valery A Podrezov 2005-09-29 04:58:55 UTC
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 gr.asl demo code attached.
Comment 1 Valery A Podrezov 2005-09-29 05:00:44 UTC
Created attachment 6181 [details]
ASL code to reproduce bug
Comment 2 Valery A Podrezov 2005-09-29 05:02:08 UTC
Created attachment 6182 [details]
proposed patch
Comment 3 Valery A Podrezov 2005-09-29 05:14:18 UTC
APPEARANCE

   While executing the AML code on a global level (out of
   any Method, immediately on a DefinitionBlock level) and
   being forced to handle some exception, ACPICA crashes
   (see the demo attached).

ROOT CAUSE

   ACPICA attempts to retrieve elements of WalkState->MethodNode
   structure which is a NULL pointer in that case (global level AML
   code execution case).

CONTENTS OF UPDATES

   1. Eliminates the cause of the crash.

   dswexec.c

   The zero value of WalkState->MethodNode for the considered
   fragment of code is now treated as an indication of the global
   level execution (see dswexec.txt). In that case the exception
   handler is passed with the zero value Name parameter. Otherwise,
   the value passed as Name parameter is the name of the Method
   (WalkState->MethodNode->Name.Integer) being executed and caused
   exception, as it was earlier.

   2. Provides the appropreate messages reported by the
      exception handler of AcpiExec utility:

   aeexec.c

   New global level execution exception case message:

      **** AcpiExec Exception: AE_AML_DIVIDE_BY_ZERO during execution on 
global level Opcode [Divide] @9

   Method execution case (old message):

      **** AcpiExec Exception: AE_AML_DIVIDE_BY_ZERO during execution of 
method [M000] Opcode [Divide] @E

ISSUE

   The change (1) above means that the interface of an exception
   handler is specified more exactly:

      zero Name parameter     - exception during global level execution
      non-zero Name parameter - exception during Method execution

   This meaning of the Name parameter of an exception handler
   should be (somewhere) explicitly specified.

REMARKS

   In a global level execution exception case (see log.txt):

   a) the message reported by
      ACPI_REPORT_ERROR (("AcpiUtDivide: Divide by zero\n"))
      is not aligned from the beginning of a new line (as it
      is usually):

         Completing Region/Field/Buffer/Package initialization:  utmath-0239: 
*** Error: AcpiUtDivide: Divide by zero

   and

   b) a dot symbol in the fragment of the message below looks strangely:

      Executing subtree for Buffer/Package/Region

        nsinit-0400 [04] NsInitOneObject       : Could not execute arguments 
for [BUF0] (Buffer), AE_AML_DIVIDE_BY_ZERO
      .

   (it is not due to the proposed update).

ISSUE

   This (see (a) and (b) of REMARKS above)
   could be filed as a new low priority bug.

UPDATED FILES

   source/tools/acpiexec/aeexec.c
   source/components/interpreter/dispatcher/dswexec.c:

HOW UPDATES WERE TESTED

   The changes are obvious, so I didn't run aslts tests,
   but checked the updates only for the relevant .asl demo program attached.
   It causes global level execution exception and shows that interpretation
   after completion of the exception processing proceeds successfully.

INTERNAL BUG NUMBER

   162
Comment 4 Valery A Podrezov 2005-09-29 05:16:28 UTC
Created attachment 6183 [details]
The attached test run output
Comment 5 Len Brown 2005-10-03 08:19:20 UTC
note that executing global level code (aka module level code)
is planned for Linux, but not yet enabled by default.
Comment 6 Robert Moore 2005-12-06 14:55:47 UTC
Integrated for next release of ACPICA
Comment 7 Robert Moore 2006-02-03 13:09:25 UTC
Released in ACPICA version 20051216
Comment 8 Len Brown 2006-07-05 17:29:51 UTC
ACPICA 20051216 shipped in Linux-2.6.16 closed.

Note You need to log in before you can comment on or make changes to this bug.