Hi there,
I am new to arduino world and I work on a project but I am not new to C/C++.
I usually do a memory allocation verification with efence or purify like libraries. Is someone already do that ? Is that work with the AVR gcc ?
Without this I spend a lot of time to find some allocation mistake or buffer overflow, efence is very good to find this. May be there is another lib for the arduino ?
Without this I spend a lot of time to find some allocation mistake or buffer overflow, efence is very good to find this.
With only a very few K of memory, finding bugs doesn't take long! ]
Not very long but with efence, just some minutes is needed 
Doesn't efence need a hardware MMU?
humm.. yes =(
May be all this kind of librarie use mmu ?
According to Wikipedia:
Electric Fence allocates at least two pages (often 8KB) for every allocated buffer. In some modes of operation, it does not deallocate freed buffers. Thus, Electric Fence vastly increases the memory requirements of programs being debugged.
Depending on which Arduino you are using, it is highly unlikely you will have two lots of 8Kb pages of memory free.
Vastly increasing the memory requirements, when you only have 2 Kb to start with on the Atmega328, is likely to introduce its own problems.
In both cases, Electric Fence causes the errant program to abort immediately via a segmentation fault.
I don't believe I have seen segmentation faults on an Arduino.
You don't see it but it can append, in this case the program stop itself
I think the 8kb can be modified at compilation
I will try later if i can do somthing with efence or other lib and will post the result here
Good luck. I note from the efence manual:
When detecting overruns, Electric Fence malloc() allocates two or more virtual memory pages for each allocation. The last page is made inaccessible in such a way that any read, write, or execute access will cause a segmentation fault.
Arduino doesn't have virtual memory. It doesn't have a method of making memory accesses cause segmentation faults.
A segmentation error implies some kind of hardware address trap that the AVR processor simply doesn't have.
There are allocation schemes that fence and check in software, but are not really suitable for memory-limited architectures - halving (or worse) an already constrained resource is not a good way to go..
The segmentation is not detected by system but append, if the program write on unauthorised data the program has random behaviour
When you talk about small memory system, I think this library is good for it, for tracking memory loss
The segmentation is not detected by system but append, if the program write on unauthorised data the program has random behaviour
Not sure what you're trying to say here - the behaviour isn't necessarily "random", but "undefined"
When you talk about small memory system, I think this library is good for it, for tracking memory loss
I don't really like relying on programming "crutches" like this - better to cure the source problem, which appears to be inappropriate use of "malloc".
When you talk about small memory system, I think this library is good for it, for tracking memory loss
Are you trying to prevent memory loss, or cause it? The second seems more likely to me.
AWOL:
The segmentation is not detected by system but append, if the program write on unauthorised data the program has random behaviour
Not sure what you're trying to say here - the behaviour isn't necessarily "random", but "undefined"
We are agree
When you talk about small memory system, I think this library is good for it, for tracking memory loss
I don't really like relying on programming "crutches" like this - better to cure the source problem, which appears to be inappropriate use of "malloc".
In my case, I need to do lot of menu, i have not enough memory to store all, I will use I2C ram to store data and malloc when needed these data
PaulS:
When you talk about small memory system, I think this library is good for it, for tracking memory loss
Are you trying to prevent memory loss, or cause it? The second seems more likely to me.
Don't sure, the efence library is just for debuging, when the program is debugged, the efence library is not needed anymore
Debug versions of the heap functions usually pad a small region before and after the allocated block with a known pattern and then check that the pattern is intact when the block is free'd. You really haven't the SRAM to do this on the Arduino. You could develop the key parts of your app on a PC with all your debug libraries and some stubs and mocks where the hardware goes then when it's bug free, port it down to the Arduino.
sam76:
When you talk about small memory system, I think this library is good for it, for tracking memory loss
I don't agree in this case. It would be fine on a PC with 4 Gb of memory, to use some of that to write an app that eventually has no memory loss.
But to use a system that requires 16 Kb of RAM, to track memory problems when you only have 2 Kb to start with, is absolutely doomed to failure. Plus, the hardware doesn't support "guard pages". Full stop.
What you could do is debug and test your core functions under Linux, and use Valgrind to check for leaks.
Another approach which is fairly widely recommended on the Arduino is not to use memory allocation at all (rather, use fixed buffers). Then you won't get memory leaks.
It's what I do for the moment. I port my objects in linux application and efence it. I have checked my code like that. I think this is the best solution.
I also gdb it like that. I have tested the simulavr but it doesn't work very well.
I have seen a JTAG interface permits a gdb directly on the board, I am under linux. Is someone tested that ? I have a JTAG with my mini2440 board, can I adapt it with arduino atmega 328 ?
sam76:
I have seen a JTAG interface permits a gdb directly on the board, I am under linux. Is someone tested that ? I have a JTAG with my mini2440 board, can I adapt it with arduino atmega 328 ?
JTAG is supported by the atmega1280 and 2560 but not the smaller Arduino's such as your 328. The JTAG pins are 4,5,6,7 on the Arduino Mega. If your JTAG debugger is supported by OpenOCD then you should be able to hook it up but you're on your own there.