> 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<<i);
>>>>
>>>> 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
[email protected]
_______________________________________________
Devel mailing list
[email protected]
https://sel4.systems/lists/listinfo/devel
