Re: Mirage/kFreeBSD on GitHub

[PALI Gabor Janos <pgj@xxxxxxx>]

On Sat, Aug 04, 2012 at 07:29:21PM +0200, PALI Gabor Janos wrote:
> On Sat, Aug 04, 2012 at 08:17:49AM -0400, Robert N. M. Watson wrote:
> > Are you able to break into the debugger using the break sequence?
> 
> No, I have not tried it yet, but I will.

Okay, I have managed to break into the debugger and it works.  However, the
"show alllock" command does not seem to give any useful clue:

db> show alllock
Process 688 (cron) thread 0xfffffe0005274480 (100050)
shared sx vm map (user) (vm map (user)) r = 0 (0xfffffe00052119a8) locked @
/usr/src/sys/vm/vm_fault.c:823
Process 12 (intr) thread 0xfffffe00022d3000 (100015)
exclusive sleep mutex Giant (Giant) r = 1 (0xffffffff8126b740) locked @
/usr/src/sys/dev/syscons/syscons.c:723


I found the mirage kernel thread in the meanwhile, though.

db> x mirage_kthread
mirage_kthread: 5273000

This helped me to find the thread with this address in the output of the
"show threads" command (which has become 100096 in my case).  Here is the
corresponding backtrace for that thread:

db> bt 100096
Tracing pid 0 tid 100096 td 0xfffffe0005273000
sched_switch() at sched_switch+0x19f
mi_switch() at mi_switch+0x208
sleepq_switch() at sleepq_switch+0xfc
sleepq_wait() at sleepq_wait+0x4d
_sleep() at _sleep+0x3fc
kmem_back() at kmem_back+0x1a3
kmem_malloc() at kmem_malloc+0x1f8
uma_large_malloc() at uma_large_malloc+0x4a
malloc() at malloc+0x15d
caml_aligned_malloc_for_major() at caml_aligned_malloc_for_major+0x2f
caml_alloc_for_heap() at caml_alloc_for_heap+0x1e
caml_alloc_shr() at caml_alloc_shr+0x10e
caml_alloc_string() at caml_alloc_string+0xbd
caml_c_call() at caml_c_call+0x20


Perhaps the rest of the kernel is just simply too busy with allocating the
requested memory?

Note that this test tries to allocate a lot of memory: 1 million instances
of strings with the given sizes: first 1, then 500, and 2500 -- that is
where the test hangs after around 372,000 allocations.  But I suppose the
garbage collector should be dropping the unused instances (since they are just
allocted, not even used) continuously, freeing up the memory on the other
side.