Re: [PATCH] Reduce gdb.base/many-headers.c iterations on Solaris [PR34555]

[Andrew Burgess <aburgess@redhat.com>]

Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:

GDB doesn't usually place bug IDs in the subject line as you're doing
here.  Instead bugs should be mentioned in the text, as you do, using
the 'PR component/number' syntax, then there should be a 'Bug: URL' tag
added at the end of the commit message.

> As detailed in PR corefiles/34555, when reading the core file in the
> gdb.base/many-headers.exp test, gdb consumes excessive amounts of memory
> on Solaris.  If left unchecked, e.g. with ulimit -Sv 8388608, the test
> will consume all available swap space.  Since Solaris doesn't do lazy
> allocation, this will cause the system to become unusably slow.
>
> To avoid this, this patch reduces the iteration count by a factor of 100.

My issue with this change is that the point of the test is to create
many headers.  If we reduce the header count then the test is no longer
doing what it says it is, and the whole test becomes, well, pointless.

I wonder if it would be better to just add this near the top of the test
script:

  if {[istarget "*-*-solaris*"]} {
      # The Solaris core file reader consumes excessive memory with many
      # program headers (PR corefiles/34555).
      kfail gdb/34555 $gdb_test_file_name
      return
  }

While looking at this I spotted that gdb.base/bigcore.exp already bails
out early for Solaris, I wonder if this is the same underlying issue?
The bug number mentioned in bigcore.exp (gdb/1551) is, I think, from
pre-bugzilla days, so I've not been able to track that to an actual bug
I could look at.

>
> Tested on sparcv9-sun-solaris2.11, x86_64-pc-solaris2.11, and
> x86_64-pc-linux-gnu.
>
> Ok for trunk and the gdb-18 branch?
>
>
> AFAICT, the issue is purely in gdb's Solaris corefile reader, which
> seems to need a complete rewrite rather than a couple of bugfixes.

Having touched lots of core file stuff recently, I'd be interested to
know more about where exactly the problem is.

Thanks,
Andrew