Re: [avr-gcc-list] problem with malloc() in avr-libc 1.6.1

[Javier Almansa Sobrino]

On Tue, 29 Jan 2008 10:57:25 +0100
David Brown <address@hidden> wrote:

> Javier Almansa Sobrino wrote:
> > Hi everybody. I'm developing a proyect with an atmega128 and I've got
> > some troubles with dinamic memory allocation.
> > 
> > I have a structure with an uint8_t pointer and tree uint16_t variables
> > inside. Initially I create a pointer for this structure and initialize
> > it with a call to malloc. Later I initialize the uint8_t pointer inside
> > the structure with another call to malloc. In this case, I initialize
> > with a lenght of 150 bytes.
> > 
> > Later, I made a lot of calls to a funcion (that is not a recursive
> > function). In this function I call malloc at the init to initialice a
> > uint8_t buffer. Later, when the function is end, I free this space.
> > 
> 
> I don't know what the problem is in your program, and whether or not it 
> is a bug in your code or the library - dynamic memory is something most 
> embedded programmers avoid whenever possible, so I haven't used the 
> avrlibc malloc.  But when have you considered alloca() instead of 
> malloc() in this situation?  It is much simpler, faster, and safer when 
> you want to release the memory at the end of the scope in which it was 
> allocated.
> 
> What are your allocation/free patterns like?  It sounds like you might 
> be getting memory fragmentation, so that you can no longer allocate 
> contiguous blocks of free memory.  But malloc() should return 0, rather 
> than hanging, if that happens.
> 
> Other than that, can you post some minimal code that illustrates your 
> problem?
> 
> mvh.,
> 
> David
Hi, this is the struct I use on my project:

typedef struct {
  /* Buffer */

  uint8_t *data; /* Data */
  uint16_t pStart; /* Start pointer */
  uint16_t pEnd; /* End pointer */
  uint16_t size; /* data size */
} bufferC_t;

In the main function, I do this:

int main (void) {
  bufferC_t *buffer;
  uint8_t count;
  volatile uint16_t c1, c2;
  __malloc_heap_start = (void *)0x808000;
  __malloc_heap_end = (void *)0x80ffff;
  wdt_disable();

  sysInit();
  rs485Init();
 
  buffer = (bufferC_t *)malloc(sizeof(bufferC_t));
  buffer -> data = (uint8_t *)malloc(DATA_LEN);

  .....................
  ......................

}


Later, I've got a function that do something like this:

void rs485Write (uint8_t addr, uint8_t len, bufferC_t *buffer) {
  
  
  uint8_t head[2];
  uint8_t c;
  uint8_t *bufferOut = (uint8_t *)malloc(sizeof(uint8_t)*(len+2));
  
  if (len > 0) {
    /*
      Si hay datos para transmitir, se crea la cabecera del mensaje
      (Direccion:Longitud)
    */
    
    bufferOut[0] = addr;
    __write(bufferOut[0]);
    bufferOut[1] = len;
    
    for (c = 0; c < len; c++) {
      pop(&bufferOut[c+2], buffer);
    }
    
    sendData (bufferOut, len+2);
  }
  free(bufferOut);
}

All works fine, but when this last function is called for a number of
times, malloc never returns.

I've changed the call of malloc for alloca and all runs fine. But I
wish to know the reason of this failure.

I whis to know if is possible to change the memory cheap where alloca
assigns memory.

Thanks


> 
> 
> > My program runs ok for a time, later it crashes. I've debugged it with
> > avarice and ddd and I've noticed the function before commented runs ok
> > for 5 or 6 times, later, when I call the malloc function this call to
> > malloc never returns. Debugging the code, I've seen the program never
> > end the step two of the malloc function. 
> > 
> > At the end of the code before any call to malloc, I initialize
> > __malloc_heap_start to 0x808000 and __malloc_heap_end to 0x80ffff. Of
> > course the external memory is activated in the early init as described
> > in avr-libc user manual and it works fine.
> > 
> > Someone knows what's the reason for this malfunction in my application?
> > It's some bug on avr-libc or is an error by me?
> > 
> > thanks.
> > 
> 
> 
> 
> 
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
> 


-- 
Nunca confies en un S.O. del que no tienes código fuente ;-)

--------------------------------
Javier Almansa Sobrino.
Ingeniero Técnico en Informática de Sistemas.

Grupo de Investigación ARCo.
Escuela Superior de Informática. Ciudad Real
Tel: (+34)926 29 53 00 Ext: 3705