RE: [ECOS] malloc vs. new

[Scott Dattalo <scott at dattalo dot com>]

On Sat, 22 Jun 2002, Dan Conti wrote:

> new shouldn't be broken, since it just calls malloc. does malloc work
> when making allocations of the exact same size?

Dan, 

I've looked into this more closely, and you're right new() just calls 
malloc(). So the next question is, how can malloc work and not new? Well, 
it turns out that malloc isn't working either. The difference between new 
and malloc is that new will through an exception whenever it's unable to 
allocate any memory. I misinterpreted the exception as a failure of new, 
when in fact the fundamental cause is a failure in malloc! In both cases 
of malloc and new, the kernel is unable to allocate any memory.

malloc works just fine in a stripped down version of a hello_world.c type 
program. So the failure I'm experiencing is somehow due to my specific 
port. Unfortunately, it's not clear to me exactly what can be causing this 
failure. As a simple test, I placed the malloc call right at the beginning 
of my program  (the big one, not the hello_world.c one) and tried 
allocating a tiny 50 byte array:

  char *test1;

  test1 = (char *) malloc(50);
/* returns null */


In my particlar application, there are several large arrays that are 100's 
of Kbytes, but these are all statically declared. Just to be sure that I 
wasn't running out of memory, I went into my ecos.ecc file and increased 
the pool size to 4 MBytes:

cdl_option CYGNUM_MEMALLOC_FALLBACK_MALLOC_POOL_SIZE {
    # Flavor: data
    user_value 4194304
    # value_source user
    # Default value: 16384
    # Legal values: 32 to 0x7fffffff
};


After making this change, I run ecosconfig tree followed by make. I then 
switch over to the directory of my application and run make there (my 
application Makefile properly refers to the ecos directory in which the 
ecos software was built).

Now for debugging the "crash". Using Insight I target the simulator, 
download and run the code. I single step through the call to malloc and 
can pin-point exactly the failure:

malloc 

 POOL.try_alloc( size );
  mypool.try_alloc();
   Cyg_Mempool_dlmalloc_Implementation::try_alloc()

within try_alloc(), there's this sequence of code:

  remainder_size = long_sub_size_t(chunksize(top), nb);
  if (chunksize(top) < nb || remainder_size < (long)MINSIZE)
  {

before the call to long_sub_size_t:

inspect /x remainder_size
$4 = 0x21333d4

but after:

inspect /x remainder_size
$5 = 0xfff4c7c0

That doesn't look right. try_alloc doesn't think so either and returns 
NULL; . 

---
I also verified that only one constructor (that wants memory) is getting 
called on startup; Cyg::StdioStream. It tries to allocate 256 bytes, but 
gets 0.


Does anyone have an idea why I'm experiencing this problem?


Scott


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