* [ECOS] malloc1 test and posix stdio fails
@ 2006-05-16 15:33 Brett Delmage
2006-05-16 15:48 ` Andrew Lunn
0 siblings, 1 reply; 5+ messages in thread
From: Brett Delmage @ 2006-05-16 15:33 UTC (permalink / raw)
To: ECOS mailing list
Posix stdio is not working on my May 9 CVS ARM lpcxxx target. I traced
this to malloc returning 0.
I started running through the memalloc tests. I am loading them into Flash
and running them using my JTAG debugger, as I would be with my
application. i.e. I'm not using the test driver or Redboot.
The following tests passed:
heaptest
dlmalloc1
dlmalloc2
kmemfix1
kmemvar1
However test malloc1 failed as follows:
INFO:<Starting tests from testcase
/ecos-c/usr/J1156-2/ecos-cvs-may9/ecos/packages/services/memalloc/common/current/test
s/malloc1.c for C library malloc(), calloc() and free() functions>
FAIL:<Can't determine allocation size to use>
Line: 103, File: /ecos-c/usr/J1156-2/ecos-cvs-may9/ecos/packages/services/
memalloc/common/current/tests/malloc1.c
EXIT:<done>
---------------------------------------
Which refers to the following code snippet:
int
main( int argc, char *argv[] )
{
int *i;
char *str, *str2, *str3;
int j;
int poolmax;
CYG_TEST_INIT();
CYG_TEST_INFO("Starting tests from testcase " __FILE__ " for C library
"
"malloc(), calloc() and free() functions");
poolmax = mallinfo().maxfree;
if ( poolmax <= 0 ) {
CYG_TEST_FAIL_FINISH( "Can't determine allocation size to use" );
}
--------------------------------------------------
So it looks like mallinfo().maxfree is not returning the correct value.
My linker file looks like this:
STARTUP(vectors.o)
ENTRY(reset_vector)
INPUT(extras.o)
GROUP(libtarget.a libgcc.a libsupc++.a)
MEMORY
{
ram : ORIGIN = 0x81200000, LENGTH = 0x200000
rom : ORIGIN = 0x00000000, LENGTH = 0x200000
}
SECTIONS
{
.debug_aranges 0 : { *(.debug_aranges) } .debug_pubnames 0 : { *(.debug_pubnames) } .debug_info 0 : { *(.debug_info) } .debug_abbrev 0 : { *(.debug_abbrev) } .debug_line 0 : { *(.debug_line) } .debug_frame 0 : { *(.debug_frame) } .debug_str 0 : { *(.debug_str) } .debug_loc 0 : { *(.debug_loc) } .debug_macinfo 0 : { *(.debug_macinfo) } .note.arm.ident 0 : { KEEP (*(.note.arm.ident)) }
.rom_vectors 0x00000000 : { __rom_vectors_vma = ABSOLUTE(.); . = .; KEEP (*(.vectors)) } > rom __rom_vectors_lma = LOADADDR(.rom_vectors);
.text ALIGN (1) : { _stext = ABSOLUTE(.); PROVIDE (__stext = ABSOLUTE(.)); *(.text*) *(.gnu.warning) *(.gnu.linkonce.t.*) *(.init) *(.glue_7) *(.glue_7t) } > rom _etext = .; PROVIDE (__etext = .);
.fini ALIGN (0x4) : { . = .; *(.fini) } > rom
.rodata ALIGN (0x4) : { . = .; *(.rodata*) *(.gnu.linkonce.r.*) } > rom
.rodata1 ALIGN (0x4) : { . = .; *(.rodata1) } > rom
.fixup ALIGN (0x4) : { . = .; *(.fixup) } > rom
.gcc_except_table ALIGN (0x4) : { . = .; *(.gcc_except_table) } > rom
.fixed_vectors 0x81200040 : { . = .; KEEP (*(.fixed_vectors)) } > ram
.data ALIGN (0x4) : AT ((LOADADDR (.gcc_except_table) + SIZEOF (.gcc_except_table) + 4 - 1) & ~ (4 - 1)) { __ram_data_start = ABSOLUTE (.); *(.data*) *(.data1) *(.gnu.linkonce.d.*) . = ALIGN (4); KEEP(*( SORT (.ecos.table.*))) ; . = ALIGN (4); __CTOR_LIST__ = ABSOLUTE (.); KEEP (*(SORT (.ctors*))) __CTOR_END__ = ABSOLUTE (.); __DTOR_LIST__ = ABSOLUTE (.); KEEP (*(SORT (.dtors*))) __DTOR_END__ = ABSOLUTE (.); *(.dynamic) *(.sdata*) *(.gnu.linkonce.s.*) . = ALIGN (4); *(.2ram.*) } > ram __rom_data_start = LOADADDR (.data); __ram_data_end = .; PROVIDE (__ram_data_end = .); _edata = .; PROVIDE (edata = .); PROVIDE (__rom_data_end = LOADADDR (.data) + SIZEOF(.data));
.bss ALIGN (0x4) : { __bss_start = ABSOLUTE (.); *(.scommon) *(.dynsbss) *(.sbss*) *(.gnu.linkonce.sb.*) *(.dynbss) *(.bss*) *(.gnu.linkonce.b.*) *(COMMON) __bss_end = ABSOLUTE (.); } > ram
__heap1 = ALIGN (0x8);
. = ALIGN(4); _end = .; PROVIDE (end = .);
---------------------------------------------------------------------------
memalloc.h:
This would seem to indicate I have 16K for heap.
#ifndef CYGONCE_PKGCONF_MEMALLOC_H
#define CYGONCE_PKGCONF_MEMALLOC_H
/*
* File <pkgconf/memalloc.h>
*
* This file is generated automatically by the configuration
* system. It should not be edited. Any changes to this file
* may be overwritten.
*/
#define CYGSEM_MEMALLOC_ALLOCATOR_FIXED_THREADAWARE 1
#define CYGSEM_MEMALLOC_ALLOCATOR_VARIABLE_THREADAWARE 1
#define CYGSEM_MEMALLOC_ALLOCATOR_VARIABLE_COALESCE 1
#define CYGPKG_MEMALLOC_ALLOCATOR_DLMALLOC 1
#define CYGDBG_MEMALLOC_ALLOCATOR_DLMALLOC_DEBUG 1
#define CYGIMP_MEMALLOC_ALLOCATOR_DLMALLOC_THREADAWARE 1
#define CYGIMP_MEMALLOC_ALLOCATOR_DLMALLOC_SAFE_MULTIPLE 1
#define CYGIMP_MEMALLOC_ALLOCATOR_DLMALLOC_USE_MEMCPY 1
#define CYGNUM_MEMALLOC_ALLOCATOR_DLMALLOC_ALIGNMENT 3
#define CYGNUM_MEMALLOC_ALLOCATOR_DLMALLOC_ALIGNMENT_3
#define CYGSEM_MEMALLOC_ALLOCATOR_SEPMETA_THREADAWARE 1
#define CYGFUN_MEMALLOC_KAPI 1
#define CYGPKG_MEMALLOC_MALLOC_ALLOCATORS 1
#define CYGBLD_MEMALLOC_MALLOC_IMPLEMENTATION_HEADER
<cyg/memalloc/dlmalloc.hxx>
#define CYGIMP_MEMALLOC_MALLOC_DLMALLOC 1
#define CYGNUM_MEMALLOC_FALLBACK_MALLOC_POOL_SIZE 16384
#define CYGNUM_MEMALLOC_FALLBACK_MALLOC_POOL_SIZE_16384
#endif
----------------------------------------------------------------
In case this is useful:
#ifndef CYGONCE_PKGCONF_HEAPS_HXX
#define CYGONCE_PKGCONF_HEAPS_HXX
/* <pkgconf/heaps.hxx> */
/* This is a generated file - do not edit! */
#define CYGMEM_HEAP_COUNT 1
#include <cyg/memalloc/dlmalloc.hxx>
extern Cyg_Mempool_dlmalloc *cygmem_memalloc_heaps[ 2 ];
#endif
/* EOF <pkgconf/heaps.hxx> */
-------------------------------------------------------
If anyone else has already seen this and fixed it or can offer suggestions
on where to look next, as I further investigate this myself, I would
appreciate it.
Brett
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ECOS] malloc1 test and posix stdio fails
2006-05-16 15:33 [ECOS] malloc1 test and posix stdio fails Brett Delmage
@ 2006-05-16 15:48 ` Andrew Lunn
2006-05-16 19:46 ` Brett Delmage
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Lunn @ 2006-05-16 15:48 UTC (permalink / raw)
To: Brett Delmage; +Cc: ECOS mailing list
On Tue, May 16, 2006 at 11:33:35AM -0400, Brett Delmage wrote:
> Posix stdio is not working on my May 9 CVS ARM lpcxxx target. I traced
> this to malloc returning 0.
>
> I started running through the memalloc tests. I am loading them into Flash
> and running them using my JTAG debugger, as I would be with my
> application. i.e. I'm not using the test driver or Redboot.
>
> The following tests passed:
>
> heaptest
> dlmalloc1
> dlmalloc2
> kmemfix1
> kmemvar1
>
> However test malloc1 failed as follows:
>
> INFO:<Starting tests from testcase
>
> /ecos-c/usr/J1156-2/ecos-cvs-may9/ecos/packages/services/memalloc/common/current/test
> s/malloc1.c for C library malloc(), calloc() and free() functions>
>
> FAIL:<Can't determine allocation size to use>
>
> Line: 103, File: /ecos-c/usr/J1156-2/ecos-cvs-may9/ecos/packages/services/
> memalloc/common/current/tests/malloc1.c
>
> EXIT:<done>
> ---------------------------------------
> Which refers to the following code snippet:
>
> int
> main( int argc, char *argv[] )
> {
> int *i;
> char *str, *str2, *str3;
> int j;
> int poolmax;
>
> CYG_TEST_INIT();
>
> CYG_TEST_INFO("Starting tests from testcase " __FILE__ " for C library
> "
> "malloc(), calloc() and free() functions");
>
> poolmax = mallinfo().maxfree;
It would be interesting to see all the return values from
mallinfo(). Could you print them out please.
> memalloc.h:
> This would seem to indicate I have 16K for heap.
>
> #define CYGNUM_MEMALLOC_FALLBACK_MALLOC_POOL_SIZE 16384
> #define CYGNUM_MEMALLOC_FALLBACK_MALLOC_POOL_SIZE_16384
No, this is unlikely to be true. This size is only used when there is
no automatic heap definition. Normally everything between the end of
the bss and top of memory is used as heap.
> ----------------------------------------------------------------
> In case this is useful:
>
> #ifndef CYGONCE_PKGCONF_HEAPS_HXX
> #define CYGONCE_PKGCONF_HEAPS_HXX
> /* <pkgconf/heaps.hxx> */
>
> /* This is a generated file - do not edit! */
>
> #define CYGMEM_HEAP_COUNT 1
> #include <cyg/memalloc/dlmalloc.hxx>
>
> extern Cyg_Mempool_dlmalloc *cygmem_memalloc_heaps[ 2 ];
>
> #endif
And this confirms that an automaticly sized heap is being used.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ECOS] malloc1 test and posix stdio fails
2006-05-16 15:48 ` Andrew Lunn
@ 2006-05-16 19:46 ` Brett Delmage
2006-05-17 16:32 ` Andrew Lunn
0 siblings, 1 reply; 5+ messages in thread
From: Brett Delmage @ 2006-05-16 19:46 UTC (permalink / raw)
To: Andrew Lunn; +Cc: ECOS mailing list
On Tue, 16 May 2006, Andrew Lunn wrote:
> > poolmax = mallinfo().maxfree;
>
> It would be interesting to see all the return values from
> mallinfo(). Could you print them out please.
All zero!
> This size is only used when there is
> no automatic heap definition. Normally everything between the end of
> the bss and top of memory is used as heap.
> And this confirms that an automaticly sized heap is being used.
Ok. Here's map from malloc1 ELF file:
Sections:
Idx Name Size VMA LMA File off Algn
7 .rom_vectors 00000040 00000000 00000000 00008000 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
8 .text 00017b04 00000040 00000040 00008040 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
9 .fini 00000000 00017b44 00017b44 000e98fe 2**0
CONTENTS
10 .rodata 00006000 00017b44 00017b44 0001fb44 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
11 .rodata1 00000000 0001db44 0001db44 000e98fe 2**0
CONTENTS
14 .fixed_vectors 00000140 81200400 81200400 000e9900 2**5
CONTENTS, READONLY
15 .data 000006b8 81200540 0001db44 00028540 2**2
CONTENTS, ALLOC, LOAD, DATA
16 .bss 00004d4c 81200bf8 81200bf8 00028bf8 2**4
ALLOC
-----------------------------------------------------------------
and a dump showing __heap1
81205948 A __heap1
81200ac0 D cygmem_memalloc_heaps
812033b4 B cygmem_pool_heap1
---------------------------
Hmm. If I do the arithmetic and I understand things correctly,
my heap pointer __heap1 = 8120 5948
which is 4 bytes past the end of bss = ( 8120 0bf8 + 0000 4d4c ) =
0x8120 5944
which would seem to be incorrect. My RAM allocation (as per my linker
file sent in previous message) ends at 8120 0000 + 20 0000 = 8140 0000
Therefore I conclude __heap1 is sent incorrectly.
Is that right?
Brett
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ECOS] malloc1 test and posix stdio fails
2006-05-16 19:46 ` Brett Delmage
@ 2006-05-17 16:32 ` Andrew Lunn
2008-09-04 14:13 ` kosuriv
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Lunn @ 2006-05-17 16:32 UTC (permalink / raw)
To: Brett Delmage; +Cc: ECOS mailing list
> 16 .bss 00004d4c 81200bf8 81200bf8 00028bf8 2**4
> ALLOC
> -----------------------------------------------------------------
> and a dump showing __heap1
>
> 81205948 A __heap1
> 81200ac0 D cygmem_memalloc_heaps
> 812033b4 B cygmem_pool_heap1
>
> ---------------------------
>
> Hmm. If I do the arithmetic and I understand things correctly,
>
> my heap pointer __heap1 = 8120 5948
> which is 4 bytes past the end of bss = ( 8120 0bf8 + 0000 4d4c ) =
> 0x8120 5944
>
> which would seem to be incorrect. My RAM allocation (as per my linker
> file sent in previous message) ends at 8120 0000 + 20 0000 = 8140 0000
>
> Therefore I conclude __heap1 is sent incorrectly.
_heap1 is the start of the heap. It is normally directly after the bss
and goes to the top of memory. So you heap should be 0x81205948 -
0x81400000
So this looks O.K. I think the problem is somewhere else.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ECOS] malloc1 test and posix stdio fails
2006-05-17 16:32 ` Andrew Lunn
@ 2008-09-04 14:13 ` kosuriv
0 siblings, 0 replies; 5+ messages in thread
From: kosuriv @ 2008-09-04 14:13 UTC (permalink / raw)
To: ecos-discuss
Hi
I am also facing the same problem, CAn you pl tell me the answer for the
same ??????????????/
Thanks
venu
Andrew Lunn-2 wrote:
>
>> 16 .bss 00004d4c 81200bf8 81200bf8 00028bf8 2**4
>> ALLOC
>> -----------------------------------------------------------------
>> and a dump showing __heap1
>>
>> 81205948 A __heap1
>> 81200ac0 D cygmem_memalloc_heaps
>> 812033b4 B cygmem_pool_heap1
>>
>> ---------------------------
>>
>> Hmm. If I do the arithmetic and I understand things correctly,
>>
>> my heap pointer __heap1 = 8120 5948
>> which is 4 bytes past the end of bss = ( 8120 0bf8 + 0000 4d4c ) =
>> 0x8120 5944
>>
>> which would seem to be incorrect. My RAM allocation (as per my linker
>> file sent in previous message) ends at 8120 0000 + 20 0000 = 8140 0000
>>
>> Therefore I conclude __heap1 is sent incorrectly.
>
> _heap1 is the start of the heap. It is normally directly after the bss
> and goes to the top of memory. So you heap should be 0x81205948 -
> 0x81400000
>
> So this looks O.K. I think the problem is somewhere else.
>
> Andrew
>
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>
>
--
View this message in context: http://www.nabble.com/malloc1-test-and-posix-stdio-fails-tp4412402p19309033.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-09-04 14:13 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-05-16 15:33 [ECOS] malloc1 test and posix stdio fails Brett Delmage
2006-05-16 15:48 ` Andrew Lunn
2006-05-16 19:46 ` Brett Delmage
2006-05-17 16:32 ` Andrew Lunn
2008-09-04 14:13 ` kosuriv
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).