• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 79 subscribers
  • Views 2034 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

calloc freezes program

Roy Stegers
Expert 1445 points


Hi All,

I'm using the MSP-EXP430F5438 with MPS430430F5438A, i'm using the SPP Demo of Bluetopia and modifid it a little. In the main right after the clock intialiation i want to calloc a memory space of 32 chars. But when i run the code the program "Freezes" when i pause the debuger i get No source available for "0x4".

Can anyone tell me why i can't allocate memory, malloc also doesn't worl

The code that i use:

char * Test_Pointer = 0;

/* will configure the hardware and initialize the OS Abstraction */
/* layer, create the Main application thread and start the scheduler.*/
int main(void)
{
/* Turn off the watchdog timer */
WDTCTL = WDTPW | WDTHOLD;

/* Configure the hardware for its intended use. */
HAL_ConfigureHardware();

Test_Pointer = (char*) calloc (32,sizeof(char)); // it hangs here

  • 0
    Guru 25210 points

    Roy Stegers said:
    No source available for "0x4"

    That is not a valid address for code execution, so the error makes sense that there is no source available. It sounds like your stack frame is getting corrupted in the call to calloc().

    Can you step into calloc() and step line by line through the function to see how you end up with PC at address 0x4 ?

  • 0
    Intellectual 450 points

    Is there a reason why you need to dynamically allocate memory? I know this doesn't exactly answer your question, but I'd recommend using static allocation (unless there is a reason you can't) instead of messing with calloc.

  • 0 in reply to psa
    Guru 25210 points

    psa said:
    Is there a reason why you need to dynamically allocate memory? I know this doesn't exactly answer your question, but I'd recommend using static allocation (unless there is a reason you can't) instead of messing with calloc.

    From the comments it looks like he has an OS layer. I also use an RTOS and malloc() memory as needed for dynamic buffers.

  • 0 in reply to Brian Boorman
    Guru 227245 points

    I can imagine a heap/stack crossover.

    To manage the arbitrary sized, dynamically allocated memory chunks, the heap management (alloc/free) requires some tracking information.

    A common way to do this efficiently is to create a daisy-chained structure. It begins with a header, containing management information, followed by a memory chunk. Initially, the header contains the size of the available heap space, along with a marker that this memory block is free and it is the last one.
    When memory is requested, the information is read and, if the available heap space is large enough for the request, the size is adjusted to the requested size, the free and last block markers are removed and another header is placed right after the allocated memory. Then a pointer to the memory right after the header is returned. Next time when memory is requested, the malloc function can travel header by header (knowing the position of the next by adding the size info of the current block).

    If memory is freed, the free function takes the pointer, subtracts the size of the header and expects a header there (or checks it by a magic word). Then it sets the ‘free’ marker and checks the previous or next block whether it is also free, to join them.

    Now it Is possible that placing the next header after the requested memory block will overwrite the return address on the stack, as the stack has (unexpectedly) grown into an area that is expected to be free for the heap. If this happens, the return from (c)alloc goes into the void.

    Check your stack size setting in the project. It does not limit the stack by any means, but will force a linker error if this ‘announced’ stack size and the heap size and the global variables exceed the available ram.
    When estimating the required stack size, take ISR calls and any local variables in nested (or even recursive) function calls into account. (We once had a case where on an MSP with 512 bytes ram, someone had a local int array of 500 elements in main. The program did compile and link without warning, but of course did never run.)

    If you use an OS and multi-threading, then every thread likely has its own stack of limited size. ISRs use the stack of the currently running thread. Be sure to allocate a large enough stack for each task. (here the project setting won't help at all)

  • 0 in reply to Jens-Michael Gross
    Expert 1445 points

    Thank you all for your answers! I'll will check it to day if i find the time and else it will be next monday. I'll will get back to you.

    Many  thanks!

**Attention** This is a public forum