This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
I somehow sent an incomplete version of this message. Please disregard. I am using newlib malloc to manage a small heap of just 256k. One of my users has sent me a pathological test which causes malloc to fail. Using C++, the test program allocates 1000 arrays of 42 integers, then deletes them all, then attempts to allocate a 64 kilobyte array. The allocation of the large array fails because malloc attempts to use sbrk to allocate new memory for the array, but there is not 64k left at the end of memory. It should not attempt to use sbrk however, because all the memory that was allocated before should be freed at that point and it should have allocated from the free space. >From my reading of the source code of 'free', when all the small arrays are deallocated, they should have been combined into a progressively bigger free chunk until they were just one giant free chunk. They are freed in the same order that they were allocated. Then, malloc should have seen that there was a sufficiently big enough chunk to allocate from and put the big array into it. Instead, it seems to be failing to find the free space and is trying to sbrk some more. It may be possible that this is a C++ problem, so I am going to rewrite this test in C to see if there is something funny going on with the C++ new[]/delete[] operators. ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |