How big should bigcore.core be?

[Andrew Cagney]

> Mark Kettenis wrote:
> 
> 
>>>If the latter is true, I really think we should disable this test by
>>>default and only enable it on systems where we know we won't generate
>>>ridiculously large files running the risk of crashing the machine.
>>>For my work on GDB, I regularly use machines that are not mine, and
>>>I'd really hate it if I crashed those.
> 
> 
> As one data point, I can confirm from experience that bigcore can
> crash an s390x-ibm-linux system hard (provided you run with memory
> overcommit and no ulimits).
> 
> Cause of crash is that it allocates a couple of terabytes heap,
> and then tries to coredump them; the Linux kernel coredump routines
> do a full address space page-table walk, which insists on creating
> all *page tables* visited, if not yet present.  For a couple of
> terabytes address space, you need a couple of gigabytes page tables,
> which are non-pagable kernel memory -- more real memory than my 
> machine had ...

So it expands the page tables without actually allocating pages :-( 
This would explain why, for amd64, it takes longer than I'd expect to 
write out a 3mb phsyical (500gb virtual) core file -> kernel bug.

> Now, running with overcommit and no ulimits on a 64-bit Linux 
> machine is something you shouldn't do anyway, but it's still
> not nice to hit this problem just from running the gdb test
> suite :-/ 

Andrew