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<<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
