How can I check how much heap space is left (or used) in my drops/oskit program? Normally (in linux/gnu) I would use getrusage, which also returns a number of other useful statistics, but this function doesn't seem to exist in drops/oskit...
Hi,
On Tue, Jul 26, 2005 at 11:11:03AM +0200, Bert van Leeuwen wrote:
How can I check how much heap space is left (or used) in my drops/oskit program? Normally (in linux/gnu) I would use getrusage, which also returns a number of other useful statistics, but this function doesn't seem to exist in drops/oskit...
In "MODE = l4env" you could use one of:
#include <oskit/lmm.h>
extern lmm_t malloc_lmm;
unsigned int free_memory = lmm_avail(&malloc_lmm, 0); lmm_dump(&malloc_lmm); lmm_stats(&malloc_lmm);
Thanks, that seems to give a likely sounding figure. Just to be sure, all new/delete/malloc/free in my program will contribute to that figure, right? I'm getting what I thought was a mem leak, since after a time calling new throws an exception, but it still seems to happen and the mem figure doesn't indicate a mem leak taking place... Is there any other reason that new would throw an exception? Perhaps heap fragmentation or something like that?
On 7/26/05, Christian Helmuth ch12@os.inf.tu-dresden.de wrote:
Hi,
On Tue, Jul 26, 2005 at 11:11:03AM +0200, Bert van Leeuwen wrote:
How can I check how much heap space is left (or used) in my drops/oskit program? Normally (in linux/gnu) I would use getrusage, which also returns a number of other useful statistics, but this function doesn't seem to exist in drops/oskit...
In "MODE = l4env" you could use one of:
#include <oskit/lmm.h>
extern lmm_t malloc_lmm;
unsigned int free_memory = lmm_avail(&malloc_lmm, 0); lmm_dump(&malloc_lmm); lmm_stats(&malloc_lmm);
-- Christian Helmuth
TU Dresden, Dept. of CS Operating Systems Group http://os.inf.tu-dresden.de/~ch12
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Curious... I just got this now instead of the exception: lmm_dump(lmm=0x017e0390) region 01000000-fffffff8 size=fefffff8 flags=00000000 pri=0 free=052bcb40 node 0x0ad31400-0ad31408 size=00000008 next=0x0ad31790 node 0x0ad31790-0ad317a0 size=00000010 next=0x0ad31810 node 0x0ad31810-0ad31818 size=00000008 next=0x0ad31da0 node 0x0ad31da0-0ad31db0 size=00000010 next=0x0ad31e20 node 0x0ad31e20-0ad31e28 size=00000008 next=0x0ad33bf8 node 0x0ad33bf8-0ad33c08 size=00000010 next=0x0ad34010 node 0x0ad34010-0ad34018 size=00000008 next=0x0ad34c40 node 0x0ad34c40-0ad34c48 size=00000008 next=0x0ad35e38 node 0x0ad35e38-0ad35e48 size=00000010 next=0x0ad3a050 node 0x0ad3a050-0ad3a058 size=00000008 next=0x0ad3a6c8 node 0x0ad3a6c8-0ad3b078 size=000009b0 next=0x0ad3c080 node 0x0ad3c080-0ad3f090 size=00003010 next=0x0ad470f8 node 0x0ad470f8-10000000 size=052b8f08 next=0x00000000 free_check=052bc938 lmm_dump.c:63: failed assertion `reg->free == free_check' PANIC. Backtrace: fp=5bffe8c 01725037 0160185c 01643260 0169fea7 01700110L4RM: [PF] read at 0x05c00000, eip 016f7f5a, src 1B.1B [1B.0] l4rm/lib/src/pagefault.c:78:__unknown_pf(): unhandled page fault
Could this perhaps indicate a double-free of a pointer somewhere or the like??
On 7/26/05, Bert van Leeuwen bert.vanleeuwen@gmail.com wrote:
Thanks, that seems to give a likely sounding figure. Just to be sure, all new/delete/malloc/free in my program will contribute to that figure, right? I'm getting what I thought was a mem leak, since after a time calling new throws an exception, but it still seems to happen and the mem figure doesn't indicate a mem leak taking place... Is there any other reason that new would throw an exception? Perhaps heap fragmentation or something like that?
On 7/26/05, Christian Helmuth ch12@os.inf.tu-dresden.de wrote:
Hi,
On Tue, Jul 26, 2005 at 11:11:03AM +0200, Bert van Leeuwen wrote:
How can I check how much heap space is left (or used) in my drops/oskit program? Normally (in linux/gnu) I would use getrusage, which also returns a number of other useful statistics, but this function doesn't seem to exist in drops/oskit...
In "MODE = l4env" you could use one of:
#include <oskit/lmm.h>
extern lmm_t malloc_lmm;
unsigned int free_memory = lmm_avail(&malloc_lmm, 0); lmm_dump(&malloc_lmm); lmm_stats(&malloc_lmm);
-- Christian Helmuth
TU Dresden, Dept. of CS Operating Systems Group http://os.inf.tu-dresden.de/~ch12
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
-- BvL
Just got a different one: lmm_dump.c:54: failed assertion `(node->size & ALIGN_MASK) == 0'
On 7/26/05, Bert van Leeuwen bert.vanleeuwen@gmail.com wrote:
Curious...
On Tue, Jul 26, 2005 at 04:28:05PM +0200, Bert van Leeuwen wrote:
Just got a different one: lmm_dump.c:54: failed assertion `(node->size & ALIGN_MASK) == 0'
Accounting your last mails, it looks like your program screws up the free memory list of the lmm allocator. Maybe you have a buffer overflow or sth. similar.
*sigh* The same program seems to work fine in linux, I've tried running it through valgrind too without problems. Unlikely as it seems, I'm starting to suspect errant behaviour in drops or oskit. Perhaps the different thread scheduling exposes a bug in my program somewhere, or perhaps the semaphores are not working as expected (in linux I get to use the pthread mutexes, no such luxury in drops/oskit)
Thanks for the help so far, Bert
On 7/26/05, Christian Helmuth ch12@os.inf.tu-dresden.de wrote:
On Tue, Jul 26, 2005 at 04:28:05PM +0200, Bert van Leeuwen wrote:
Just got a different one: lmm_dump.c:54: failed assertion `(node->size & ALIGN_MASK) == 0'
Accounting your last mails, it looks like your program screws up the free memory list of the lmm allocator. Maybe you have a buffer overflow or sth. similar.
Hi,
On Wed, Jul 27, 2005 at 09:16:48AM +0200, Bert van Leeuwen wrote:
Perhaps the different thread scheduling exposes a bug in my program somewhere, or perhaps the semaphores are not working as expected (in linux I get to use the pthread mutexes, no such luxury in drops/oskit)
Huh? Maybe I'm overlooking sth. but in L4Env we have locks and semaphores - pkg/lock resp. pkg/semaphore. From my experience, these do their work. The client library of the DOpE GUI also has a simple wrapping layer in pkg/dope/lib/dope/include/sync.h and pkg/dope/lib/dope/{l4,linux}/sync.c.
If you were aware of the locking libraries just ignore this email ;)
I've been using pkg/semaphore, but maybe I'll have a look at pkg/lock, thanks for reminding me about it!
On 7/27/05, Christian Helmuth ch12@os.inf.tu-dresden.de wrote:
Hi,
On Wed, Jul 27, 2005 at 09:16:48AM +0200, Bert van Leeuwen wrote:
Perhaps the different thread scheduling exposes a bug in my program somewhere, or perhaps the semaphores are not working as expected (in linux I get to use the pthread mutexes, no such luxury in drops/oskit)
Huh? Maybe I'm overlooking sth. but in L4Env we have locks and semaphores
- pkg/lock resp. pkg/semaphore. From my experience, these do their work.
The client library of the DOpE GUI also has a simple wrapping layer in pkg/dope/lib/dope/include/sync.h and pkg/dope/lib/dope/{l4,linux}/sync.c.
If you were aware of the locking libraries just ignore this email ;)
People probably aren't going to be believe me, but this is what I've found: I looked at all the scenarios which made my program crash, and compared to the ones that did not. A number of differences in program flow was identified, and by process of elimination I found the culprit leading to my memory corruption bug:
I replaced std::queue with std::list in one part of my program, and used list::push_back and list::pop_front instead of queue::push and queue::pop. This simple change causes the program to not crash anymore in L4.... Curious. So be warned: if you notice weird behaviour in your program in L4, and you're using std::queue, then that might be a factor... Possibly the version of STL included in l4/pkg/libstdc++ has an obscure bug in std::queue, as unlikely as it seems...
On 7/27/05, Bert van Leeuwen bert.vanleeuwen@gmail.com wrote:
*sigh* The same program seems to work fine in linux, I've tried running it through valgrind too without problems. Unlikely as it seems, I'm starting to suspect errant behaviour in drops or oskit. Perhaps the different thread scheduling exposes a bug in my program somewhere, or perhaps the semaphores are not working as expected (in linux I get to use the pthread mutexes, no such luxury in drops/oskit)
During my mem debugging effort I came across a useful thing. I'm sure all the gurus on this list already know about it, but for the benefit of the other oskit/l4 newbs like me, this is particulary useful:
http://www.cs.utah.edu/flux/oskit/html/oskit-wwwch31.html#x45-284600031
You can just link oskit_memdebug into your program (before -loskit_freebsd_c or whichever version you use), and it can help you find all sorts of memory problems.
On 7/28/05, Bert van Leeuwen bert.vanleeuwen@gmail.com wrote:
People probably aren't going to be believe me, but this is what I've found: I looked at all the scenarios which made my program crash, and compared to the ones that did not. A number of differences in program flow was identified, and by process of elimination I found the culprit leading to my memory corruption bug:
I replaced std::queue with std::list in one part of my program, and used list::push_back and list::pop_front instead of queue::push and queue::pop. This simple change causes the program to not crash anymore in L4.... Curious. So be warned: if you notice weird behaviour in your program in L4, and you're using std::queue, then that might be a factor... Possibly the version of STL included in l4/pkg/libstdc++ has an obscure bug in std::queue, as unlikely as it seems...
On 7/27/05, Bert van Leeuwen bert.vanleeuwen@gmail.com wrote:
*sigh* The same program seems to work fine in linux, I've tried running it through valgrind too without problems. Unlikely as it seems, I'm starting to suspect errant behaviour in drops or oskit. Perhaps the different thread scheduling exposes a bug in my program somewhere, or perhaps the semaphores are not working as expected (in linux I get to use the pthread mutexes, no such luxury in drops/oskit)
l4-hackers@os.inf.tu-dresden.de