Bug 5422

Summary:	Memory leak till the Method exit for each execution of If(TRUE)-Else/ElseIf
Product:	ACPI	Reporter:	Valery A Podrezov (Valery.A.Podrezov)
Component:	ACPICA-Core	Assignee:	Valery A Podrezov (Valery.A.Podrezov)
Status:	CLOSED CODE_FIX
Severity:	normal	CC:	acpi-bugzilla
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6	Subsystem:
Regression:	---	Bisected commit-id:
Attachments:	ASL code to reproduce bug. Bug-fixing patch

Description Valery A Podrezov 2005-10-12 10:06:05 UTC

Most recent kernel where this bug did not occur:
Distribution:
Hardware Environment:
Software Environment:
Problem Description:

This is some type of "memory leak" bug (similar to 110 internal bug).
The Linux kernel ACPI interpreter after completion the AML
If(TRUE)-Else/ElseIf operation doesn't release some memory allocations.

This issue has been revealed by the automated "Per-method execution
memory consumption verification debug service" (PMEMCV) designed in
those purposes and is not seen by the "Outstanding allocation" service
(OAS). The summary amount of unused memory allocations increases per each
run to that operation until the Method termination when only all the
lists of memory allocations attached to that method are finally released.
This type "memory leaks" are just revealed by PMEMCV when the memory is
ineffectively used during the Method interpretation time.

So if an OEM BIOS includes this code, the total effectiveness of memory
consumption of Linux would decrease.

Steps to reproduce:

Run interpreter with the .asl demo code attached below
to observe the slowing down of interpretation visually.

Comment 1 Valery A Podrezov 2005-10-12 10:08:02 UTC

Created attachment 6285 [details]
ASL code to reproduce bug.

The attached AML test being run on the Linux kernel ACPI interpreter
when it is compiled into a simulator allows to observe the problem.
Each time when the If branch is executed but Else (or ElseIf) is omitted
new memory leaks are produced:

   Name(i000, 1)
   if (i000) {
       Store(lpC0, Debug)
   } else {
       Store(lpN0, Debug)
   }

To make the problem visual the demo runs this operation in a
long enough cycle (0xA000 repetitions). So that you even can
observe the slowing down of interpretation visually.


INTERNAL BUG NUMBER

   156

Comment 2 Valery A Podrezov 2005-12-05 02:41:26 UTC

Created attachment 6769 [details]
Bug-fixing patch


The patch essentially decreases the time of execution of programs like given by
demo.

A. Time of execution of demo program BEFORE update:

   CYGWIN_NT-5.1 1.5.18(0.132/4/2) 2005-07-02 20:30 i686 unknown unknown Cygwin


      3 minutes 42 seconds (+ noise of swapping)

   Linux 2.6.5-7.191-smp #1 SMP Tue Jun 28 14:58:56 UTC 2005 i686 i686 i386
GNU/Linux

      2 minutes 59 seconds (+ noise of swapping)

B. Time of execution of demo program AFTER update:

   CYGWIN_NT-5.1 1.5.18(0.132/4/2) 2005-07-02 20:30 i686 unknown unknown Cygwin


		16 seconds (NO noise of swapping)

   Linux 2.6.5-7.191-smp #1 SMP Tue Jun 28 14:58:56 UTC 2005 i686 i686 i386
GNU/Linux

		16 seconds (NO noise of swapping)


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
- 32-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 (no new errors).

Comment 3 Robert Moore 2005-12-06 14:38:31 UTC

Integrated for next release of ACPICA

Comment 4 Robert Moore 2006-02-03 13:13:26 UTC

Released in ACPICA version 20051216