Dear all,
i tried to use TinyAlloc interface but the results are really similar. So
this is not a problem of the calloc function.
But i start thinking the problem is in the stack. If i post too many tasks, can
the mote crash?
The problem is that i have to use tasks to handle the FlashBridge interface in
order to use properly the reading and writing phase on Flash-RAM. And i'm also
using a task for the sending interface (own mote messages) and for the
forwarding one (messages from other motes), all synchronized by timers.
So if i use micaz motes, tinyos-1.x, can it be a problem?
Because i'm freeing all the times the memory i allocate, but if i repeat the
experiments with the motes on, in the second round or in the third one, one (or
more)of these breaks down. It seems quite randomly.
Hoping in any kind of help,
cheers
Daniele
-----Original Message-----
From: David Moss [mailto:[EMAIL PROTECTED]
Sent: Mon 9/11/2006 7:56 PM
To: Munaretto, Daniel; tinyos-help@Millennium.Berkeley.EDU
Cc:
Subject: RE: [Tinyos-help] repeating tests,no free memory
Daniele,
This was one thing I noticed about the code I looked at but failed to
warn
against, because I didn't know any better until I read up on it
afterwards.
Below are a few emails from this list that may point you in the right
direction.
-David
https://mail.millennium.berkeley.edu/pipermail/tinyos-help/2005-February/007
712.html :
"The TinyOS programming methodology frowns on malloc, for several
reasons:
1) No memory protection so you can smash your stack
2) Unforeseen rate mismatches can cause you to do 1 (you start
receiving packets faster than you can forward them)
3) Event-driven execution models can make free()ing a hard thing to do
right (hence pool allocations, etc.)
If you want dynamic allocation, look at TinyAlloc (which Joe
mentioned). It allows you to allocate a static chunk of RAM which you
then parcel out dynamically. But using it in the presence of
conflicting components is a recipe for disaster. Systems such as TinyDB
get away with it because all their parts are designed to work together.
Phil"
"Hi all,
Refer to the paper "The NesC Language: A Holistic Approach to
Networked Embedded Systems", dynamic memory allocation and function
pointers are prohibited in NesC language. For dynamic memory
allocation, it's quite clear to me why we can't use it in TinyOS as
refered to
https://mail.millennium.berkeley.edu/pipermail/tinyos-help/2005-February/007
712.html
. We can use TinyAlloc or MemAlloc instead of directly calling
malloc() and so on. But for function pointers, it's not clear to me
that we can or can't use it in TinyOS. What would be the problems if I
use that?"
"Short answer: it leads to more reliable code.
Long answer:
Here's a pointer (haha!):
http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2005-February/0077
12.html
There's a difference between malloc() and dynamic allocation. nesC
does not forbid dynamic memory allocation: there's nothing stopping
you from writing a component that allocates a pool of memory and has
dynamic allocation interfaces. Take a look at TinyAlloc, for example.
nesC does, however, frown on malloc, for the reasons described in the
above mail. Modern coding styles generally assume unbounded memory,
in as much that you have swap space so will see tremendous
performance degradation before the system crashes. General
application behavior on allocation failure is to exit(2) and
therefore deallocate everything. With a processes, multitasking, and
automatic page reclamation, this works fine. But on an embedded
system with no memory protection, well, it's not so clean.
Part of the issue is that while dynamic allocation among a set of
cooperating components can work fine (e.g., TinyDB, Ben Greenstein
@UCLA's work on signal processing), dynamic allocation between
arbitrary components (a single shared pool) is a recipe for disaster.
One bad component can bring the entire system down, as the shared
resource breaks inter-component isolation.
The reason why nesC frowns on function pointers is because they are
dangerous and except for a few edge cases (e.g., dynamically linking
new binary modules), unnecessary. You know the call graph at compile-
time. Instead of storing a function pointer in memory, which could be
corrupted and lead you to jump to certain doom, you can just use a
parameterized interface and call based on a function ID. This also
gives you type checking for the functions It is more robust, just as
easy (once you get used to it), and generally uses less RAM (no need
to store the pointer). Function pointers are a basic result of C's
linking model. nesC's linking model does not have the same
complications (interfaces are bidirectional), so you can avoid them.
Phil"
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Munaretto,
Daniel
Sent: Monday, September 11, 2006 1:51 AM
To: tinyos-help@Millennium.Berkeley.EDU
Subject: [Tinyos-help] repeating tests,no free memory
Dear all,
i discover a really strange behavior in my application.
I repeat more times my code, and after some experiments the motes break
down.
So there is a memory problem.
But i'm sure i free all the memory i allocate during the code. I'm
using
only a buffer and i re-use it all the times, instead i allocate memory
with
"calloc()" only for creating a chain which i delete at the end of each
simulation with the "free" command and then i give "NULL" to the
pointers.
So i don't understand where i lose memory each time i re-run the
program
(without re-booting the motes). i'm in tinyos 1.1.15,micaz motes.
I'm using the FlashBridge interface because i'm working on the flash.
I'm supposing that, may be, the problem is in the way Tinyos handles
the
packets received. For example, in the function "event TOS_MsgPtr
Receive.receive(TOS_MsgPtr m)", before returning m, do i have to free
it?But
i can see it's wrong to do..
Please, if anyone knows where i have to find the waste of memory (may
be
some interfaces)...any helps will be really appreciated
thanks very much
cheers
Daniele
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
