Userspace allocator cannot handle big sizes

[Jiri Svoboda]

As of revision mainline,236, if I create a disk image on tmpfs, create a FAT filesystem on it, mount it and create a file, it crashes. To reproduce, follow these steps:

# mkfile --size 2m /scratch/img
# file_bd /scratch/img bd/fdev0
# mkfat bd/fdev0
# mkdir /fat
# mount fat /fat bd/fdev0
# mkfile --size 32k /fat/test

The command appears to be hung, in klog we can see that Thread 0x80083000 crashed at 0x1af76 (_heap+0x7f76). FP = 0x80028438. The stack trace appears to be bogus:

  0x80028438: 0x1af76 (_heap+0x7f76)
Warning: udebug_mem_read() failed.

[Jiri Svoboda]

Repeating the same with 180k image size gave me a different stack trace, which I painstakingly copied here:

Trhead 0x80083000 crashed at 0xbd4b (malloc_internal+0x1cb). FP = 0x1af14
  0x1af14: 0xbd4b (malloc_internal+0x1cb)
  0x1af64: 0xc1b5 (realloc+0xd5)
  0x1afb4: 0x1c77 (tmpfs_write+0x77)
  0x1aff4: 0x1379 (tmpfs_connection+0x1c9)
  0x1b024: 0xd83b (connection_fibril+0x1b)
  0x1b044: 0x8127 (fibril_main+0x17)

[Jakub Jermář]

The second example is still reproducible as of head,250.

From the "coredump" data and the kill message, it looks like the task it touching unmapped memory, 8 bytes behind the end of an address space area. Are we growing the heap insufficiently?

[Jakub Jermář]

Screenshot showing the stack trace, address space areas and the kill message.

[Jakub Jermář]

Core file with memory contents of the crashed tmpfs.

[Jakub Jermář]

I think this is an allocator bug.

From the attached screenshot and core file, we have:

(gdb) printf "%p\n", &_heap
0x14000
(gdb) inspect heap_pages
$5 = 101
(gdb) printf "%x\n", 101*4096
65000
(gdb) printf "%p\n", heap_end
0x79000

So both according to the kernel address space areas and the heap variables, the heap ends at 0x79000, but the allocator touched 0x79008 which killed the task. The offending instruction is:

0x0000bd6b <malloc_internal+459>: movl $0xbeef0101,0x8(%edx)

where 0xbeef0101 is a magic pattern used by the allocator to mark the heap block footer.

[Jakub Jermář]

TMPFS binary which produced the already attached core file.

[Jakub Jermář]

I found a simple reproducible test case, based on the file system behavior above:

=== modified file 'uspace/app/tester/mm/malloc1.c'
--- uspace/app/tester/mm/malloc1.c	2009-08-04 11:19:19 +0000
+++ uspace/app/tester/mm/malloc1.c	2010-02-10 21:01:41 +0000
@@ -629,6 +629,8 @@
 
 char *test_malloc1(void)
 {
+	realloc(malloc(184320), 4294965248ULL);
+
 	init_mem();
 	
 	unsigned int phaseno;

[Jakub Jermář]

Fixed in changeset:head,263.