#488 TLSF DeletePool recoverable alert

[Oliver Brunner]

If you allocate 384 MB memory in a pool and then delete the
pool afterwards, a recoverable alert occurs.

Ignoring the alert seems to cause no problems.

Log:

[MM] Chunk allocator error
[MM] Attempt to free 3450834832 bytes at 0x0000000041a461e0
[MM] The block does not belong to any MemHeader

*** Logged alert:

Program failed
Task : 0x0000000041FBFDF0 - foo
Error: 0x0100000F - Memory header not located
PC   : 0x0000000060851825
Module boot/linux/kernel Segment 1 .text (0x0000000060831000) Offset
0x0000000000020825
Function __inline_Exec_Alert (0x00000000608517F8) Offset 0x000000000000002D
Stack trace:
0x000000006085211F boot/linux/kernel Function nommu_FreeMem +
0x00000000000001F4
0x0000000060850F71 boot/linux/kernel Function FreeMemHeader +
0x0000000000000089
0x00000000608446DC boot/linux/kernel Function Exec_117_DeletePool +
0x0000000000000187
0x000000004238CEB9 System:foo Function _ZL24__inline_Exec_DeletePoolPvS_ +
0x0000000000000030
0x000000004238CFCC System:foo Function main + 0x00000000000000D6
0x000000004238CE41 System:foo Function __startup_main + 0x0000000000000027
0x000000004238E80B System:foo Function ___startup_entries_next +
0x0000000000000043
0x000000004238D11E System:foo Function __stdc_startup + 0x0000000000000042
0x000000004238E80B System:foo Function ___startup_entries_next +
0x0000000000000043
0x000000004238DBC3 System:foo Function __initcommandline + 0x00000000000001A0

Smaller allocation are no problem.

Code of testprogram foo.cpp:

#include <stdio.h>
#include <cstdlib>
#include <proto/exec.h>

/* 384 MB */
#define BYTES 384 * 1024 * 1024

APTR valloc_pool;

int main () {

  APTR mem;

  valloc_pool= CreatePool(MEMF_CLEAR, 16384, 8192);
  printf("valloc_pool: %lx\n", valloc_pool);
  if(!valloc_pool) {
    printf("ERROR: unable to CreatePool!\n");
    exit(1);
  }

  mem=AllocPooled(valloc_pool, BYTES);
  if(!mem) {
    printf("WARNING: test not possible, not enough memory!\n");
  }
  else {
    printf("allocated %d bytes in pool %lx: %lx\n", BYTES, valloc_pool, mem);
  }

  DeletePool(valloc_pool);
  printf("Pool deleted\n");

  return 0;
}

This happens on ABI v1/x86_64 hosted, exe compiled with x86_64-aros-gcc.

Neil Cafferkey wrote on the AROS-Dev list (8.10.2015):

I can reproduce this crash in linux-x86_64 but not in linux-i386 (both
built from an up-to-date source tree yesterday). I used "-m 1024" when
starting AROS.

The crash doesn't occur if AROS is started with the "notlsf" option.

[Nick Andrews]

On 14 October 2015 at 14:40, Oliver Brunner o1i@users.sf.net wrote:

---

• [bugs:#488] http://sourceforge.net/p/aros/bugs/488/ TLSF DeletePool
  recoverable alert*

Status: open
Group: general
Created: Wed Oct 14, 2015 01:40 PM UTC by Oliver Brunner
Last Updated: Wed Oct 14, 2015 01:40 PM UTC
Owner: nobody

If you allocate 384 MB memory in a pool and then delete the
pool afterwards, a recoverable alert occurs.

Ignoring the alert seems to cause no problems.

Log:
[MM] Chunk allocator error
[MM] Attempt to free 3450834832 bytes at 0x0000000041a461e0
[MM] The block does not belong to any MemHeader

*** Logged alert:

Program failed
Task : 0x0000000041FBFDF0 - foo
Error: 0x0100000F - Memory header not located
PC : 0x0000000060851825
Module boot/linux/kernel Segment 1 .text (0x0000000060831000) Offset
0x0000000000020825
Function

inline_Exec_Alert (0x00000000608517F8) Offset 0x000000000000002D Stack
trace: 0x000000006085211F boot/linux/kernel Function nommu_FreeMem +
0x00000000000001F4 0x0000000060850F71 boot/linux/kernel Function
FreeMemHeader + 0x0000000000000089 0x00000000608446DC boot/linux/kernel
Function Exec_117_DeletePool + 0x0000000000000187 0x000000004238CEB9
System:foo Function _ZL24inline_Exec_DeletePoolPvS_ +
0x0000000000000030
0x000000004238CFCC System:foo Function main + 0x00000000000000D6
0x000000004238CE41 System:foo Function

startup_main + 0x0000000000000027 0x000000004238E80B System:foo Function
startup_entries_next + 0x0000000000000043 0x000000004238D11E System:foo
Function __stdc_startup + 0x0000000000000042 0x000000004238E80B System:foo
Function startup_entries_next + 0x0000000000000043 0x000000004238DBC3
System:foo Function initcommandline + 0x00000000000001A0

Smaller allocation are no problem.

Code of testprogram foo.cpp:

include <stdio.h>#include <cstdlib>#include <proto exec.h="">

/ 384 MB /#define BYTES 384 * 1024 * 1024
APTR valloc_pool;
int main () {

APTR mem;

valloc_pool= CreatePool(MEMF_CLEAR, 16384, 8192);
printf("valloc_pool: %lx\n", valloc_pool);
if(!valloc_pool) {
printf("ERROR: unable to CreatePool!\n");
exit(1);
}

mem=AllocPooled(valloc_pool, BYTES);
if(!mem) {
printf("WARNING: test not possible, not enough memory!\n");
}
else {
printf("allocated %d bytes in pool %lx: %lx\n", BYTES, valloc_pool, mem);
}

DeletePool(valloc_pool);
printf("Pool deleted\n");

return 0;}

This happens on ABI v1/x86_64 hosted, exe compiled with x86_64-aros-gcc.

Neil Cafferkey wrote on the AROS-Dev list (8.10.2015):

I can reproduce this crash in linux-x86_64 but not in linux-i386 (both
built from an up-to-date source tree yesterday). I used "-m 1024" when
starting AROS.

The crash doesn't occur if AROS is started with the "notlsf" option.

---

I frequently see pool related crashes using wanderer on ABI v1
(hosted/native) and have seen reports of similar on AROS Exec. I also am
investigating some issues in the animation datatype that seem to be related
to the use of pools. One file in particular crashes without fail when
closing (a 1bp bitmap) but doesn't when -notlsf is specified.

Is there some incompatibility between pools/tlsf? or is it a sign of memory
getting trashed?

[Kalamatee]

This seems to be quite a mjor issue. Just about anything using pools seems to be able to trigger it on deletion of the pool.

[Michal Schulz]

Commit r51491 seems to fix the bug. Once tested and verified the bug can be closed.

[Krzysztof Smiechowicz]

Confirmed by o1i on dev-ml. Closing the bug.