public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: David Brennan <eCos@brennanhome.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: eCos Discussion List <ecos-discuss@sources.redhat.com>
Subject: Re: [ECOS] Memory allocation failure
Date: Tue, 10 May 2005 10:03:00 -0000	[thread overview]
Message-ID: <42804FE0.7020101@brennanhome.com> (raw)
In-Reply-To: <20050508093601.GO31731@lunn.ch>



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

  reply	other threads:[~2005-05-10  6:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-06 13:57 David Brennan
2005-05-06 20:46 ` Andrew Lunn
2005-05-07  7:54   ` David Brennan
2005-05-09  8:16     ` Andrew Lunn
2005-05-10 10:03       ` David Brennan [this message]
2005-05-07 16:19 ` Edgar Grimberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42804FE0.7020101@brennanhome.com \
    --to=ecos@brennanhome.com \
    --cc=andrew@lunn.ch \
    --cc=ecos-discuss@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).