From: Jeff D. <jd...@ka...> - 2001-07-16 17:36:18
|
rc...@im... said: > GProf support does not seem to be working with 4um. It compiles, but > when I try to boot the uml kernel, I get a kernel BUG message. Hmmm, I'll have a look at this. Jeff |
From: Jeff D. <jd...@ka...> - 2001-08-01 23:58:02
|
rc...@im... said: > 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... Jeff |
From: Jeff D. <jd...@ka...> - 2001-08-04 01:46:28
|
jd...@ka... said: > 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... Jeff |
From: Jeff D. <jd...@ka...> - 2001-08-05 03:20:37
|
rc...@im... said: > cr2 = 0x1023b334} > 101b2000-1023b000 rwxs 00000000 03:05 19 /tmp/vm_file-aAGdqA > (deleted) That's what I thought. The fault is just off the end of the tracing thread's brk. 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 necessary. 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. Jeff |