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.
The application is subscribed on this signal. On receipt, system
( "free" ); is called and is showing
sufficient free memory.
The stacktrace shows that a vector.push_back( ... ) is done on
receipt of SIGILL.
I suspect the problem is some memory issue?
I investigated some mail threads, etc. and I have the following
questions;
- 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.
On some operating systems designed for non-mmu architectures, I've
seen the use of "handles", a pointer to a pointer, which enables the
operating system to relocate the data and update the handle at well
defined times. This allows the operating system to compact the heap,
at the cost of the application needing to be mindful of when this
might happen, requiring it to lock handles at critical times, and of
course requiring double-dereferencing of non-locked handles.
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
_______________________________________________
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
