On Sun, Apr 01, 2007 at 09:10:02AM -0400, Jeff Dike wrote:
> On Sun, Apr 01, 2007 at 07:45:47AM +0200, jez wrote:
> > Yep, that's an improvement alright. I changed the address prefix from
> > 0xbf down to 0xbb on the stub defaults and now I'm getting:
> > -- Output --
> > EXT3-fs: mounted filesystem with ordered data mode.
> > VFS: Mounted root (ext3 filesystem) readonly.
> > line_ioctl: tty0: ioctl KDSIGACCEPT called
> > INIT: version 2.86 booting
> > *** glibc detected *** double free or corruption (!prev): 0x08051068 ***
> > -- End --
> Hmm, I've never seen that before.
It's quite odd. I also tried using 0x60 and also putting them between the
stack and the end of user-space mem at 0xbfafe000. Each time I get the
same error, with the same address, 0x08051068.
-- Output --
(gdb) x 0x08051068
0x8051068 <alloc_node_mem_map+72>: 0xac868bc3
(gdb) disassemble 0x08051068
Dump of assembler code for function alloc_node_mem_map:
0x08051068 <alloc_node_mem_map+72>: ret
-- End --
I've tried rebooting the outer UML, and I also tried statically
compiling the inner UML. No change yet though. Hey, at least it's
> > > ... or it needs to be something that can be set from the command line.
> > You mean so that all UMLs could be used something like:
> > ./vmlinux --level 1
> Yeah, CONFIG_STUB_* would turn into something like
> CONFIG_STUB_* -level*2*PAGE_SIZE
Now here's something strange. I initially assumed that there were only
two pages, so when I was changing the stub mappings, I first tried:
What's wired is that this returns the mmap error:
mapping mmap stub failed, errno = 12
Kernel panic - not syncing: start_userspace : expected SIGSTOP, got status = 256
This got me to thinking that maybe the CONFIG_STUB_START indicated the
top of a downward-growing stack or something. Are you saying that these
pages should actually be free, or have I just misunderstood?