From: Jeff Dike <jdike@ka...> - 2001-08-01 23:58:02
> I tried to add a breakpoint to __free_pages() function and I noticed
> that instead of the expected 0, we have a huge number as order, what
> leads to that kernel BUG message.
So, where's that huge number coming from? It can't be too hard to track down.
Send stack traces. Inquiring minds want to know...
From: Jeff Dike <jdike@ka...> - 2001-08-04 01:46:28
> Here's a theory - the faulting address will be some reasonable heap
> address (i.e. 0x80xxxxx), but if you look at the maps of the tracing
> thread, you will see that the heap doesn't extend that far.
Ummm, that should have been 0x100xxxxx...
From: Jeff Dike <jdike@ka...> - 2001-08-05 03:20:37
> cr2 = 0x1023b334}
> 101b2000-1023b000 rwxs 00000000 03:05 19 /tmp/vm_file-aAGdqA
That's what I thought. The fault is just off the end of the tracing thread's
You've tripped over one of the nastier bits of UML's memory management.
Because libc can call malloc, which can extend the brk in the process doing
the malloc, and because all data needs to be shared between all UML threads,
the brk is copied into a shared memory segement, and whenever a context switch
happens, the outgoing process checks to see if it extended the brk and copies
the new data into that segment, and the incoming process maps it in if
So, what's happening is that some other thread extended the brk, but the
tracing thread wasn't updated to reflect that. So malloc considered that it
had memory out beyond the tracing thread's brk, tried to access it and faulted.