Allon Stern wrote:
On Jul 1, 2008, at 6:12 AM, Teun Grinwis wrote:
I execute an application on uClinux which uses intensively stl vectors.
It regularly creates and clears vectors, and this vectors are growing.
After some days the application is killed by the kernel with signal
SIGILL.
<snip>
- The kernel struct mmap contains start_brk, brk, context.end_brk.
Is end_brk - start_brk, the max heap allowed to allocate by the
application??
start_brk: Initial address of the heap
brk: current final address ot the heap
Since you are intensively creating and freeing memory, have you
considered that you might be fragmenting your heap, leading to the
situation of having plenty of free memory available, but due to
allocated blocks fragmenting it, you don't have a large enough
contiguous block to allocate what you need.
<snip>
Since Linux is designed for an MMU'ed system, the memory subsystem must
make necessary compromises for nonMMU architectures. I suspect you might
be running into some of the compromises.
Then again, this is just conjecture, since I have very limited
experience with uClinux. Someone more knowledgeable, please chime in and
tell me if I'm full of crap, please :)
-
allon
allon,
i think you are on target here (not necessarily a nonMMU issue though).
aka garbage collection. not good in a real time system (but necessary
for the memory hogs like C++ [cough JAVA]).
1. garbage collection for the heap must be performed as low priority
back ground or slack-time.
2. Don't use C++ in a small embedded system with no garbage collection
schema. Or only use the C++ functionality that doesn't constantly use
new and deletes and memory alloc/reallocs.
Which memory allocation system is being used SLOB or SLAB, out of curiosity?
thnx - bob
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
