public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [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).