[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[avr-libc-dev] [Bug #2143] malloc() routines chunk smaller than requeste
From: |
nobody |
Subject: |
[avr-libc-dev] [Bug #2143] malloc() routines chunk smaller than requested |
Date: |
Mon, 06 Jan 2003 17:02:42 -0500 |
=================== BUG #2143: LATEST MODIFICATIONS ==================
http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=2143&group_id=2140
Changes by: Joerg Wunsch <address@hidden>
Date: 2003-Jan-06 23:02 (Europe/Berlin)
What | Removed | Added
---------------------------------------------------------------------------
Assigned to | None | joerg_wunsch
------------------ Additional Follow-up Comments ----------------------------
malloc() is my baby.
=================== BUG #2143: FULL BUG SNAPSHOT ===================
Submitted by: None Project: AVR C Runtime Library
Submitted on: 2003-Jan-06 16:18
Category: Library Severity: 5 - Major
Bug Group: None Resolution: None
Assigned to: joerg_wunsch Originator Email: address@hidden
Status: Open
Summary: malloc() routines chunk smaller than requested
Original Submission:
I believe I've found in bug that exists in the malloc() implementation in the
snapshots from 17dec2002 and 04nov2002.
Here's (basically) the code I'm running:
char *ptrs[32];
__malloc_heap_start = 0x8000;
__malloc_heap_end = 0xFFFF;
for (j = 0; j < 32; j++) {
ptrs[j] = (char *)malloc(1024);
/* output j and ptrs[j] to serial port */
}
I would expect the last malloc() to return NULL, since there's not 1024 bytes
left in the heap. Instead, I get the following output:
0 = 00008002
1 = 00008404
2 = 00008806
-cut-
29 = 0000f43c
30 = 0000f83e
31 = 0000fc40
The last malloc() returns a chunk of memory that is only 959 bytes before the
end of the heap!
Follow-up Comments
*******************
-------------------------------------------------------
Date: 2003-Jan-06 23:02 By: joerg_wunsch
malloc() is my baby.
CC list is empty
No files currently attached
For detailed info, follow this link:
http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=2143&group_id=2140