> 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
