[ECOS] Memory allocation failure

[ECOS] Memory allocation failure

[David Brennan]

I have created two different applications with the same eCos 
configuration and essentially the same code base. One trivial 
application which is missing most of the meat of the main application. 
The trivial application runs fine. However when I try and start the real 
application, it dies during my static constructors. I have traced the 
problem down to a malloc call, but GDB eventually hangs while trying to 
single step through there. It always hangs at this one particular 
malloc, when constructing one particular instantiation of a class. Any 
ideas? Is there a fixed number of pool elements which can be allocated 
using dlmalloc?
Target is i386 VME based PC.

I have asserts turned on.

gdb output:
{my code here}
902         while( (p = (heapBlockHeaderT*) malloc(nSizeWithHeader)) == 
NULL )
(gdb) s
malloc (size=160)
    at 
/ecos-c/cygwin/opt/ecos/Applications/ecos/install/include/cyg/memalloc/dlmalloc.hxx:133
133         try_alloc( cyg_int32 size ) { return mypool.try_alloc( size ); }
(gdb) s
432             sched_lock++;
(gdb) n
251         CYG_ASSERTCLASS( this, "Bad this pointer");
(gdb)
358     {
(gdb)
403         if( this == NULL ) return false;
(gdb)
394     {
(gdb)
253         cyg_uint8 *ret = pool.try_alloc( size );
(gdb) p mypool
$1 = {pool = {arenabase = 0x26f830 "U\211å\203ì\b\203ì\bhÿÿ", arenasize 
= 2559322, av_ = {
      0x27118a, 0x273668, 0x274142, 0x277820, 0x27a0d0, 0x27b808, 
0x27c34c, 0x27d278, 0x27e116,
      0x27faa0, 0x28019a, 0x280434, 0x2819f0, 0x282528, 0x282c00, 
0x28341e, 0x283590, 0x283fde,
      0x284540, 0x2863e2, 0x286954, 0x287a6a, 0x287cf8, 0x2882c0, 
0x2886d0, 0x28c59a, 0x28cb7e,
      0x28cc44, 0x28ceda, 0x290a88, 0x2911dc, 0x291360, 0x2922f4, 
0x29321a, 0x2935a4, 0x29613a,
      0x2965be, 0x296844, 0x297348, 0x299fc4, 0x29b650, 0x29e0b4, 
0x29e146, 0x29e680, 0x29eeba,
      0x29fd86, 0x2a109c, 0x2a186c, 0x2a1ffa, 0x2a2b32, 0x2a54ac, 
0x2a5a48, 0x2a8a5a, 0x2b90f0,
      0x2e1eac, 0x2ade8c, 0x2c7eec, 0x2ccfa8, 0x2c1610, 0x2c1da0, 
0x2c1684, 0x2df5b0, 0x2e31b0,
      0x2ae3a4, 0x2c8dfc, 0x2ca95c, 0x2cafbc, 0x2ad124, 0x2bf3a8, 
0x2bac14, 0x2c8604, 0x2e109c,
      0x2bad20, 0x2bb3a4, 0x2bcb44, 0x2b7ee0, 0x208db2, 0x2097aa, 
0x212b92, 0x22f2fa, 0x231ddc,
      0x232262, 0x2652e0, 0x266466, 0x26b084, 0x26b8f8, 0x26f84a, 
0x2711a4, 0x273682, 0x27415c,
      0x27783a, 0x27a0ea, 0x27b822, 0x27c366, 0x27e130, 0x27faba, 
0x2801b4, 0x281a0a, 0x282542,
      0x282c1a, 0x283438, 0x2863fc, 0x287a84, 0x287d12, 0x2882da, 
0x2886ea, 0x28c5b4, 0x28cb98,
      0x28cc5e, 0x28cef4, 0x290aa2, 0x29137a, 0x29230e, 0x2935be, 
0x296154, 0x2965d8, 0x297362,
      0x299fde, 0x29b66a, 0x29e0ce, 0x29eed4, 0x29fda0, 0x2a10b6, 
0x2a2014, 0x2a2b4c, 0x2a54c6,
      0x2a5a62, 0x2a8a74, 0x2c7f04, 0x2c1628, 0x2c1db8, 0x2c169c, 
0x2df5c8, 0x2e31c8, 0x2ae3bc,
      0x2c8e14, 0x2ca974, 0x2cafd4, 0x2bf3c0, 0x2bac2c, 0x2e10b4, 
0x2bb3bc, 0x2bcb5c, 0x0, 0x0,
      0x0, 0x0, 0x0, 0x0, 0x0, 0x2dc2dc, 0x0, 0x39ad86, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x2cbe98, 0x0,
      0x399d3a, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2e40f4, 0x0, 0x39c6d9, 0x0, 
0x0, 0x0, 0x0, 0x0,
      0x2ccfc0, 0x0, 0x39a1e4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2d8c1c, 0x0, 
0x39abec, 0x0, 0x0, 0x0,
      0x0, 0x0, 0x2d8be8, 0x39efa0, 0x39a61c, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x2d8be8, 0x39e960...}},
  queue = {<Cyg_ThreadQueue_Implementation> = {<Cyg_CList_T<Cyg_Thread>> 
= {<Cyg_CList> = {
          head = 0x2ae3dc}, <No data fields>}, <No data fields>}, <No 
data fields>}}
(gdb) s


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Memory allocation failure

[Andrew Lunn]

On Fri, May 06, 2005 at 06:57:19AM -0700, David Brennan wrote:
> I have created two different applications with the same eCos 
> configuration and essentially the same code base. One trivial 
> application which is missing most of the meat of the main application. 
> The trivial application runs fine. However when I try and start the real 
> application, it dies during my static constructors. I have traced the 
> problem down to a malloc call, but GDB eventually hangs while trying to 
> single step through there. It always hangs at this one particular 
> malloc, when constructing one particular instantiation of a class. Any 
> ideas? Is there a fixed number of pool elements which can be allocated 
> using dlmalloc?
> Target is i386 VME based PC.

A total guess.....

You say this is a constructor. When is the constructor called? Is it a
static constructor which will be called early during startup? Have you
checked that malloc's constructor has already been called so that
malloc itself is read to be called?

        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

Re: [ECOS] Memory allocation failure

[David Brennan]

Andrew Lunn wrote:

>On Fri, May 06, 2005 at 06:57:19AM -0700, David Brennan wrote:
>  
>
>>I have created two different applications with the same eCos 
>>configuration and essentially the same code base. One trivial 
>>application which is missing most of the meat of the main application. 
>>The trivial application runs fine. However when I try and start the real 
>>application, it dies during my static constructors. I have traced the 
>>problem down to a malloc call, but GDB eventually hangs while trying to 
>>single step through there. It always hangs at this one particular 
>>malloc, when constructing one particular instantiation of a class. Any 
>>ideas? Is there a fixed number of pool elements which can be allocated 
>>using dlmalloc?
>>Target is i386 VME based PC.
>>    
>>
>
>A total guess.....
>
>You say this is a constructor. When is the constructor called? Is it a
>static constructor which will be called early during startup? 
>
It is a static constructor, using the default constructor init priority. 
However, the application has already run a lot of other static 
constructors by the time this happens. (Our application actually has its 
own heap manager, which says that we have allocated over 10Meg of heap 
around the time of the crash.)

Another engineer posed the question to me, "Whose stack are the 
constructors using, and how big is it?" A question which I cannot 
answer. Is there a configuration option for that stack space? We had a 
problem with VxWorks, which tried to run all of the constructors with 
too small of a stack.

>Have you
>checked that malloc's constructor has already been called so that
>malloc itself is read to be called?
>
>  
>
Based on the population of the mypool variable, it looks like the 
constructor ran. I did not specifically test that. But I would assume 
that would be a problem for all of eCos if the malloc is not one of the 
first things constructed.

Dave

>        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

Re: [ECOS] Memory allocation failure

[Andrew Lunn]

> Another engineer posed the question to me, "Whose stack are the 
> constructors using, and how big is it?" A question which I cannot 
> answer. Is there a configuration option for that stack space? We had a 
> problem with VxWorks, which tried to run all of the constructors with 
> too small of a stack.

That could be your problem. Constructors are called with the interrupt
stack. You can control the size of this with
CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE

        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

Re: [ECOS] Memory allocation failure

[David Brennan]

Andrew Lunn wrote:

>>Another engineer posed the question to me, "Whose stack are the 
>>constructors using, and how big is it?" A question which I cannot 
>>answer. Is there a configuration option for that stack space? We had a 
>>problem with VxWorks, which tried to run all of the constructors with 
>>too small of a stack.
>>    
>>
>
>That could be your problem. Constructors are called with the interrupt
>stack. You can control the size of this with
>CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE
>
>  
>
I tried this, (changed from 4192 to 65536) and absolutely no difference. 
While trying to debug this, I did find something curious, maybe or maybe 
not relevant.

(gdb) s
malloc (size=160)
    at 
/ecos-c/cygwin/opt/ecos/Applications/ecos/install/include/cyg/memalloc/dlmalloc.hxx:133
133         try_alloc( cyg_int32 size ) { return mypool.try_alloc( size ); }
(gdb) p mypool
$2 = {pool = {arenabase = 0x26f830 "U\211å\203ì\b\203ì\bhÿÿ", arenasize 
= 2559322, av_ = {
      0x27118a, 0x273668, 0x274142, 0x277820, 0x27a0d0, 0x27b808, 
0x27c34c, 0x27d278, 0x27e116,
      0x27faa0, 0x28019a, 0x280434, 0x2819f0, 0x282528, 0x282c00, 
0x28341e, 0x283590, 0x283fde,
      0x284540, 0x2863e2, 0x286954, 0x287a6a, 0x287cf8, 0x2882c0, 
0x2886d0, 0x28c59a, 0x28cb7e,
      0x28cc44, 0x28ceda, 0x290a88, 0x2911dc, 0x291360, 0x2922f4, 
0x29321a, 0x2935a4, 0x29613a,
      0x2965be, 0x296844, 0x297348, 0x299fc4, 0x29b650, 0x29e0b4, 
0x29e146, 0x29e680, 0x29eeba,
      0x29fd86, 0x2a109c, 0x2a186c, 0x2a1ffa, 0x2a2b32, 0x2a54ac, 
0x2a5a48, 0x2a8a5a, 0x2b90f0,
      0x2e1eac, 0x2ade8c, 0x2c7eec, 0x2ccfa8, 0x2c1610, 0x2c1da0, 
0x2c1684, 0x2df5b0, 0x2e31b0,
      0x2ae3a4, 0x2c8dfc, 0x2ca95c, 0x2cafbc, 0x2ad124, 0x2bf3a8, 
0x2bac14, 0x2c8604, 0x2e109c,
      0x2bad20, 0x2bb3a4, 0x2bcb44, 0x2b7ee0, 0x208db2, 0x2097aa, 
0x212b92, 0x22f2fa, 0x231ddc,
      0x232262, 0x2652e0, 0x266466, 0x26b084, 0x26b8f8, 0x26f84a, 
0x2711a4, 0x273682, 0x27415c,
      0x27783a, 0x27a0ea, 0x27b822, 0x27c366, 0x27e130, 0x27faba, 
0x2801b4, 0x281a0a, 0x282542,
      0x282c1a, 0x283438, 0x2863fc, 0x287a84, 0x287d12, 0x2882da, 
0x2886ea, 0x28c5b4, 0x28cb98,
      0x28cc5e, 0x28cef4, 0x290aa2, 0x29137a, 0x29230e, 0x2935be, 
0x296154, 0x2965d8, 0x297362,
      0x299fde, 0x29b66a, 0x29e0ce, 0x29eed4, 0x29fda0, 0x2a10b6, 
0x2a2014, 0x2a2b4c, 0x2a54c6,
      0x2a5a62, 0x2a8a74, 0x2c7f04, 0x2c1628, 0x2c1db8, 0x2c169c, 
0x2df5c8, 0x2e31c8, 0x2ae3bc,
      0x2c8e14, 0x2ca974, 0x2cafd4, 0x2bf3c0, 0x2bac2c, 0x2e10b4, 
0x2bb3bc, 0x2bcb5c, 0x0, 0x0,
      0x0, 0x0, 0x0, 0x0, 0x0, 0x2dc2dc, 0x0, 0x39ad86, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x2cbe98, 0x0,
      0x399d3a, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2e40f4, 0x0, 0x39c6d9, 0x0, 
0x0, 0x0, 0x0, 0x0,
      0x2ccfc0, 0x0, 0x39a1e4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2d8c1c, 0x0, 
0x39abec, 0x0, 0x0, 0x0,
      0x0, 0x0, 0x2d8be8, 0x39efa0, 0x39a61c, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x2d8be8, 0x39e960...}},
  queue = {<Cyg_ThreadQueue_Implementation> = {<Cyg_CList_T<Cyg_Thread>> 
= {<Cyg_CList> = {
          head = 0x2ae3dc}, <No data fields>}, <No data fields>}, <No 
data fields>}}
(gdb) p *cygmem_memalloc_heaps[0]
$3 = {mypool = {pool = {arenabase = 0x490c60 "", arenasize = 63369120, 
av_ = {0x0, 0x0, 0xf0ec10,
        0x3e13c8, 0x3e13d0, 0x3e13d0, 0x3e13d8, 0x3e13d8, 0x3e13e0, 
0x3e13e0, 0x3e13e8, 0x3e13e8,
        0x3e13f0, 0x3e13f0, 0x3e13f8, 0x3e13f8, 0x3e1400, 0x3e1400, 
0x3e1408, 0x3e1408, 0x3e1410,
        0x3e1410, 0x3e1418, 0x3e1418, 0x3e1420, 0x3e1420, 0x3e1428, 
0x3e1428, 0x3e1430, 0x3e1430,
        0x3e1438, 0x3e1438, 0x3e1440, 0x3e1440, 0x3e1448, 0x3e1448, 
0x3e1450, 0x3e1450, 0x3e1458,
        0x3e1458, 0x3e1460, 0x3e1460, 0x3e1468, 0x3e1468, 0x3e1470, 
0x3e1470, 0x3e1478, 0x3e1478,
        0x3e1480, 0x3e1480, 0x3e1488, 0x3e1488, 0x3e1490, 0x3e1490, 
0x3e1498, 0x3e1498, 0x3e14a0,
        0x3e14a0, 0x3e14a8, 0x3e14a8, 0x3e14b0, 0x3e14b0, 0x3e14b8, 
0x3e14b8, 0x3e14c0, 0x3e14c0,
        0x3e14c8, 0x3e14c8, 0x3e14d0, 0x3e14d0, 0x3e14d8, 0x3e14d8, 
0x3e14e0, 0x3e14e0, 0x3e14e8,
        0x3e14e8, 0x3e14f0, 0x3e14f0, 0x3e14f8, 0x3e14f8, 0x3e1500, 
0x3e1500, 0x3e1508, 0x3e1508,
        0x3e1510, 0x3e1510, 0x3e1518, 0x3e1518, 0x3e1520, 0x3e1520, 
0x3e1528, 0x3e1528, 0x3e1530,
        0x3e1530, 0x3e1538, 0x3e1538, 0x3e1540, 0x3e1540, 0x3e1548, 
0x3e1548, 0x3e1550, 0x3e1550,
        0x3e1558, 0x3e1558, 0x3e1560, 0x3e1560, 0x3e1568, 0x3e1568, 
0x3e1570, 0x3e1570, 0x3e1578,
        0x3e1578, 0x3e1580, 0x3e1580, 0x3e1588, 0x3e1588, 0x3e1590, 
0x3e1590, 0x3e1598, 0x3e1598,
        0x3e15a0, 0x3e15a0, 0x3e15a8, 0x3e15a8, 0x3e15b0, 0x3e15b0, 
0x3e15b8, 0x3e15b8, 0x3e15c0,
        0x3e15c0, 0x3e15c8, 0x3e15c8, 0x3e15d0, 0x3e15d0, 0x3e15d8, 
0x3e15d8, 0x3e15e0, 0x3e15e0,
        0x3e15e8, 0x3e15e8, 0x3e15f0, 0x3e15f0, 0x3e15f8, 0x3e15f8, 
0x3e1600, 0x3e1600, 0x3e1608,
        0x3e1608, 0x3e1610, 0x3e1610, 0x3e1618, 0x3e1618, 0x3e1620, 
0x3e1620, 0x3e1628, 0x3e1628,
        0x3e1630, 0x3e1630, 0x3e1638, 0x3e1638, 0x3e1640, 0x3e1640, 
0x3e1648, 0x3e1648, 0x3e1650,
        0x3e1650, 0x3e1658, 0x3e1658, 0x3e1660, 0x3e1660, 0x3e1668, 
0x3e1668, 0x3e1670, 0x3e1670,
        0x3e1678, 0x3e1678, 0x3e1680, 0x3e1680, 0x3e1688, 0x3e1688, 
0x3e1690, 0x3e1690, 0x3e1698,
        0x3e1698, 0x3e16a0, 0x3e16a0, 0x3e16a8, 0x3e16a8, 0x3e16b0, 
0x3e16b0, 0x3e16b8, 0x3e16b8,
        0x3e16c0, 0x3e16c0, 0x3e16c8, 0x3e16c8, 0x3e16d0, 0x3e16d0, 
0x3e16d8, 0x3e16d8...}},
    queue = {<Cyg_ThreadQueue_Implementation> = 
{<Cyg_CList_T<Cyg_Thread>> = {<Cyg_CList> = {
            head = 0x0}, <No data fields>}, <No data fields>}, <No data 
fields>}}}
I'm not sure why these are not the same. And I am not sure which is 
"correct". I did notice that mypool's arenabase and arenasize are almost 
equal. The second seems more likely since my processor has 64Meg of memory.

I also have a question regarding gdb debugging. Is there a way to print 
the results of mallinfo while I have the program "broken"? I tried 'p 
mallinfo()'. But I get the following error message: 'Attempt to use a 
type name as an expression'. I noticed that mallinfo is the name of the 
function and the name of the return type.

Thanks
David Brennan

>        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

Re: [ECOS] Memory allocation failure

[Edgar Grimberg]

A total guess here, also...

This happened to me not a long time ago.. I have wrote way over the 
memory I have allocated with malloc (I am still ashamed) and, after some 
steps, when trying to create another object, operator new returned me a 
big fat NULL. Of course, the problem was caused by my array index out of 
bound type of bug.

How to check if this is your problem... try using ||struct mallinfo 
mallinfo|(void); 
(http://ecos.sourceware.org/docs-latest/ref/malloc-pools.html)  and 
check the free memory. If you see something strange there... you must 
check if you don't get over your allocated memory.



Good luck,
Edgar||||
|

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss