We have made some changes to muslc. If you diff against changeset '615629bd6fcd6ddb69ad762e679f088c7bd878e2' you can see them. In particular there are some changes to malloc that you could try reverting.

Unfortunately, I am using a relatively fresh version of seL4 and corresponding libraries (3.2.x). The last sync with master trees was made just before MCP was added (mid of September), thus, the diff with master is just the last x86-related commit :(

Adrian

On Fri 04-Nov-2016 8:58 AM, Vasily A. Sartakov wrote:

...

Greetings.

I am keep working, and now I would like to discuss my second memory-related issue. In contrast with first one, the second issue happens only in SCHED004 test, in malloc function:

helper_thread_t **threads = (helper_thread_t **) malloc(sizeof(helper_thread_t*) * NUM_PRIOS);

malloc dies because there is no record inside TLB. someone tries to write something to an address, for example, 0x54f1c8. This address is important because it is located outside of the virtual memory allocated for the test. Previous, elf_loader allocates a region and the region ends exactly on 0x54efff. I have experimented with different setups, added some debug functions, and each time I saw the same picture: malloc dies because tries to write to next page outside the allocated region.

I know what is the function tries to write. It is a pretrim, part of libmuslc:

static int pretrim(struct chunk *self, size_t n, int i, int j) { size_t n1; struct chunk *next, *split;

/* We cannot pretrim if it would require re-binning. */ if (j < 40) return 0; if (j < i+3) { if (j != 63) return 0; n1 = CHUNK_SIZE(self); if (n1-n <= MMAP_THRESHOLD) return 0; } else { n1 = CHUNK_SIZE(self); } if (bin_index(n1-n) != j) return 0;

next = NEXT_CHUNK(self); printf("next - %x, n1 = %x\n", next, n1); split = (void *)((char *)self + n); <————— the split points outside the allocated region split->prev = self->prev; <————— here we die split->next = self->next; split->prev->next = split; split->next->prev = split; split->psize = n | C_INUSE; split->csize = n1-n; next->psize = n1-n; self->csize = n | C_INUSE; return 1; }

As a previous, I would like to ask, should I keep in mind something platform specific? maybe you have modified, like a_and asm functions or something else in libmuslc? Also, malloc itself raises questions:

void *malloc(size_t n) { struct chunk *c; int i, j;

if (adjust_size(&n) < 0) return 0;

<….>

i = bin_index_up(n); for (;;) { uint64_t mask = mal.binmap & -(1ULL<

mal.binmap is used uninitialised. also, when we set up bits inside it? Moreover, I have different values on ARM (0x80000000000) and MIPS (0x8000000000000000), I am not sure that it is ok

Thank you!

-- Vasily A. Sartakov sartakov@ksyslabs.org

I don't understand what you are saying. If you're on a recent version of seL4 then that commit should definitely be there, as it's a merge from december last year. Also don't see how MCP is relevant, it caused zero changes to muslc.

I am using musllibc library from ‘b5c66eef4a8bb274d7a4b9b5b82bce412224dbf9' commit

Adrian

On Fri 04-Nov-2016 10:19 AM, Vasily A. Sartakov wrote:

...

...

We have made some changes to muslc. If you diff against changeset '615629bd6fcd6ddb69ad762e679f088c7bd878e2' you can see them. In particular there are some changes to malloc that you could try reverting.

Unfortunately, I am using a relatively fresh version of seL4 and corresponding libraries (3.2.x). The last sync with master trees was made just before MCP was added (mid of September), thus, the diff with master is just the last x86-related commit :(

...

Adrian

On Fri 04-Nov-2016 8:58 AM, Vasily A. Sartakov wrote:

...

Greetings.

I am keep working, and now I would like to discuss my second memory-related issue. In contrast with first one, the second issue happens only in SCHED004 test, in malloc function:

helper_thread_t **threads = (helper_thread_t **) malloc(sizeof(helper_thread_t*) * NUM_PRIOS);

malloc dies because there is no record inside TLB. someone tries to write something to an address, for example, 0x54f1c8. This address is important because it is located outside of the virtual memory allocated for the test. Previous, elf_loader allocates a region and the region ends exactly on 0x54efff. I have experimented with different setups, added some debug functions, and each time I saw the same picture: malloc dies because tries to write to next page outside the allocated region.

I know what is the function tries to write. It is a pretrim, part of libmuslc:

static int pretrim(struct chunk *self, size_t n, int i, int j) { size_t n1; struct chunk *next, *split;

/* We cannot pretrim if it would require re-binning. */ if (j < 40) return 0; if (j < i+3) { if (j != 63) return 0; n1 = CHUNK_SIZE(self); if (n1-n <= MMAP_THRESHOLD) return 0; } else { n1 = CHUNK_SIZE(self); } if (bin_index(n1-n) != j) return 0;

next = NEXT_CHUNK(self); printf("next - %x, n1 = %x\n", next, n1); split = (void *)((char *)self + n); <————— the split points outside the allocated region split->prev = self->prev; <————— here we die split->next = self->next; split->prev->next = split; split->next->prev = split; split->psize = n | C_INUSE; split->csize = n1-n; next->psize = n1-n; self->csize = n | C_INUSE; return 1; }

As a previous, I would like to ask, should I keep in mind something platform specific? maybe you have modified, like a_and asm functions or something else in libmuslc? Also, malloc itself raises questions:

void *malloc(size_t n) { struct chunk *c; int i, j;

if (adjust_size(&n) < 0) return 0;

<….>

i = bin_index_up(n); for (;;) { uint64_t mask = mal.binmap & -(1ULL<

mal.binmap is used uninitialised. also, when we set up bits inside it? Moreover, I have different values on ARM (0x80000000000) and MIPS (0x8000000000000000), I am not sure that it is ok

Thank you!

-- Vasily A. Sartakov sartakov@ksyslabs.org

Hi

git diff 615629bd6fcd6ddb69ad762e679f088c7bd878e2 b5c66eef4a8bb274d7a4b9b5b82bce412224dbf9

will let you see all the changes we have made from the base muslc, or just

git diff 615629bd6fcd6ddb69ad762e679f088c7bd878e2 b5c66eef4a8bb274d7a4b9b5b82bce412224dbf9 -- src/malloc/malloc.c

to see the changes to malloc that I was referring to

Ahh, sorry, now I got you. I fount the problem. I do not know why, but arch/mips/bits/limits.h does not have '#define PAGE_SIZE 4096’, like in arm version: #if defined(_POSIX_SOURCE) || defined(_POSIX_C_SOURCE) \ || defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) || defined(_BSD_SOURCE) #define PAGE_SIZE 4096 #define LONG_BIT 32 #endif #define LONG_MAX 0x7fffffffL #define LLONG_MAX 0x7fffffffffffffffLL As result, constructions like this: n += -n & PAGE_SIZE-1; from void *__expand_heap(size_t *pn) does not work. Now I have OOM due stack allocation, but I think I will solve it. Thank you

Adrian

On Fri 04-Nov-2016 10:52 AM, Vasily A. Sartakov wrote:

...

...

I don't understand what you are saying. If you're on a recent version of seL4 then that commit should definitely be there, as it's a merge from december last year. Also don't see how MCP is relevant, it caused zero changes to muslc.

I am using musllibc library from ‘b5c66eef4a8bb274d7a4b9b5b82bce412224dbf9' commit

...

Adrian

On Fri 04-Nov-2016 10:19 AM, Vasily A. Sartakov wrote:

...

...

We have made some changes to muslc. If you diff against changeset '615629bd6fcd6ddb69ad762e679f088c7bd878e2' you can see them. In particular there are some changes to malloc that you could try reverting.

Unfortunately, I am using a relatively fresh version of seL4 and corresponding libraries (3.2.x). The last sync with master trees was made just before MCP was added (mid of September), thus, the diff with master is just the last x86-related commit :(

...

Adrian

On Fri 04-Nov-2016 8:58 AM, Vasily A. Sartakov wrote:

...

Greetings.

I am keep working, and now I would like to discuss my second memory-related issue. In contrast with first one, the second issue happens only in SCHED004 test, in malloc function:

helper_thread_t **threads = (helper_thread_t **) malloc(sizeof(helper_thread_t*) * NUM_PRIOS);

malloc dies because there is no record inside TLB. someone tries to write something to an address, for example, 0x54f1c8. This address is important because it is located outside of the virtual memory allocated for the test. Previous, elf_loader allocates a region and the region ends exactly on 0x54efff. I have experimented with different setups, added some debug functions, and each time I saw the same picture: malloc dies because tries to write to next page outside the allocated region.

I know what is the function tries to write. It is a pretrim, part of libmuslc:

static int pretrim(struct chunk *self, size_t n, int i, int j) { size_t n1; struct chunk *next, *split;

/* We cannot pretrim if it would require re-binning. */ if (j < 40) return 0; if (j < i+3) { if (j != 63) return 0; n1 = CHUNK_SIZE(self); if (n1-n <= MMAP_THRESHOLD) return 0; } else { n1 = CHUNK_SIZE(self); } if (bin_index(n1-n) != j) return 0;

next = NEXT_CHUNK(self); printf("next - %x, n1 = %x\n", next, n1); split = (void *)((char *)self + n); <————— the split points outside the allocated region split->prev = self->prev; <————— here we die split->next = self->next; split->prev->next = split; split->next->prev = split; split->psize = n | C_INUSE; split->csize = n1-n; next->psize = n1-n; self->csize = n | C_INUSE; return 1; }

As a previous, I would like to ask, should I keep in mind something platform specific? maybe you have modified, like a_and asm functions or something else in libmuslc? Also, malloc itself raises questions:

void *malloc(size_t n) { struct chunk *c; int i, j;

if (adjust_size(&n) < 0) return 0;

<….>

i = bin_index_up(n); for (;;) { uint64_t mask = mal.binmap & -(1ULL<

mal.binmap is used uninitialised. also, when we set up bits inside it? Moreover, I have different values on ARM (0x80000000000) and MIPS (0x8000000000000000), I am not sure that it is ok

Thank you!

-- Vasily A. Sartakov sartakov@ksyslabs.org