Re: [RFA/testsuite] Some feedback about bigcore.exp...

Re: [RFA/testsuite] Some feedback about bigcore.exp...

[Michael Elizabeth Chastain]

My thoughts ...

It's really more of a per-site thing, which to me means an environment
variable.  I know the dejagnu way would be to set a variable in site.exp
but I really prefer to work with environment variables.

The default is to run the test in order to flush out more bugs on more
architectures but perhaps we could have an easy way to suppress this
test and then document that way.  It's tough to run a regression test
suite when one of the 300 test scripts bangs so many operating systems
so hard.

The core file should not fill up the disk as long as the operating
system and the file system dump core files as sparse files.
(Cheat sheet: think of a file as an array of blocks.  For a "sparse
file", the file system does not store blocks which are all 0's.
All the system calls like read(2) and write(2) work normally but there
are less blocks needed on the disk than the size of the file.)

I'm running red hat linux 8 with kernel 2.4.8-14 on an ext3 file system
and my core files are sparse.  What kernel/file-system do you have
where the core files actually take up that much space?

I wish there were a portable way to compress sparse files quickly and
easily.  I'm using "tar cSf ..." to manage these files followed by bzip2
but that is gnu-specific.

Michael C

Re: [RFA/testsuite] Some feedback about bigcore.exp...

[Michael Elizabeth Chastain]

My thoughts ...

It's really more of a per-site thing, which to me means an environment
variable.  I know the dejagnu way would be to set a variable in site.exp
but I really prefer to work with environment variables.

The default is to run the test in order to flush out more bugs on more
architectures but perhaps we could have an easy way to suppress this
test and then document that way.  It's tough to run a regression test
suite when one of the 300 test scripts bangs so many operating systems
so hard.

The core file should not fill up the disk as long as the operating
system and the file system dump core files as sparse files.
(Cheat sheet: think of a file as an array of blocks.  For a "sparse
file", the file system does not store blocks which are all 0's.
All the system calls like read(2) and write(2) work normally but there
are less blocks needed on the disk than the size of the file.)

I'm running red hat linux 8 with kernel 2.4.8-14 on an ext3 file system
and my core files are sparse.  What kernel/file-system do you have
where the core files actually take up that much space?

I wish there were a portable way to compress sparse files quickly and
easily.  I'm using "tar cSf ..." to manage these files followed by bzip2
but that is gnu-specific.

Michael C

Re: [RFA/testsuite] Some feedback about bigcore.exp...

[Joel Brobecker]

> I'm running red hat linux 8 with kernel 2.4.8-14 on an ext3 file system
> and my core files are sparse.  What kernel/file-system do you have
> where the core files actually take up that much space?

I didn't know about this feature. On my linux laptop (2.6 kernel with
ext3), ls says I get a corefile of the following size: 2014404608.
However, the execution of the test is almost instantaneous, so I suspect
it's sparse too. Is there a way to know the physical size?

However, I also regularly run the testsuite on other platforms,
and it did hurt :-/...

-- 
Joel

Re: [RFA/testsuite] Some feedback about bigcore.exp...

[Joel Brobecker]

> I'm running red hat linux 8 with kernel 2.4.8-14 on an ext3 file system
> and my core files are sparse.  What kernel/file-system do you have
> where the core files actually take up that much space?

I didn't know about this feature. On my linux laptop (2.6 kernel with
ext3), ls says I get a corefile of the following size: 2014404608.
However, the execution of the test is almost instantaneous, so I suspect
it's sparse too. Is there a way to know the physical size?

However, I also regularly run the testsuite on other platforms,
and it did hurt :-/...

-- 
Joel

Re: [RFA/testsuite] Some feedback about bigcore.exp...

[Daniel Jacobowitz]

On Fri, Mar 12, 2004 at 08:42:02PM -0800, Joel Brobecker wrote:
> > I'm running red hat linux 8 with kernel 2.4.8-14 on an ext3 file system
> > and my core files are sparse.  What kernel/file-system do you have
> > where the core files actually take up that much space?
> 
> I didn't know about this feature. On my linux laptop (2.6 kernel with
> ext3), ls says I get a corefile of the following size: 2014404608.
> However, the execution of the test is almost instantaneous, so I suspect
> it's sparse too. Is there a way to know the physical size?

Yes: try 'du core'.

> However, I also regularly run the testsuite on other platforms,
> and it did hurt :-/...

I still think we should require a whitelist for this test as a matter
of pragmatism.  It's not nice to our users if they download GDB 6.1,
build it on Some Supported Non-Linux Operating System, run "make
check", and it eats their machine alive.

Does anyone know of any operating system _other_ than Linux that supports
dumping cores as sparse files?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/testsuite] Some feedback about bigcore.exp...

[Daniel Jacobowitz]

On Fri, Mar 12, 2004 at 08:42:02PM -0800, Joel Brobecker wrote:
> > I'm running red hat linux 8 with kernel 2.4.8-14 on an ext3 file system
> > and my core files are sparse.  What kernel/file-system do you have
> > where the core files actually take up that much space?
> 
> I didn't know about this feature. On my linux laptop (2.6 kernel with
> ext3), ls says I get a corefile of the following size: 2014404608.
> However, the execution of the test is almost instantaneous, so I suspect
> it's sparse too. Is there a way to know the physical size?

Yes: try 'du core'.

> However, I also regularly run the testsuite on other platforms,
> and it did hurt :-/...

I still think we should require a whitelist for this test as a matter
of pragmatism.  It's not nice to our users if they download GDB 6.1,
build it on Some Supported Non-Linux Operating System, run "make
check", and it eats their machine alive.

Does anyone know of any operating system _other_ than Linux that supports
dumping cores as sparse files?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

[RFA/testsuite] Some feedback about bigcore.exp...

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 962 bytes --]

Hello,

Just FYI, in case others may feel the same way?

We have now run this test pretty much on most of our Unix native
platforms, and have found that the bigcore.exp testcase is usually quite
stressful for the host where the testing is being conducted. For
instance, on sparc-solaris, the system ran out of virtual memory and
swap space, and started killing processes at random. It also requires a
very large amount of disk space to be available for the core file (2GB
on x86-linux). So I was told by other fellow machine users to please
stop running this test on our build machines.

One thing I would recommend is to delete the core file once the test is
finished. I had a testsuite run that got ruined because the core file
filled up all my disk, and left no space available for the rest of the
run...

2004-03-12  J. Brobecker  <brobecker@gnat.com>

        * gdb.base/bigcore.exp: Delete core file after test has completed.

Sounds reasonable?

-- 
Joel

[-- Attachment #2: bigcore.exp --]
[-- Type: text/plain, Size: 506 bytes --]

Index: bigcore.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/bigcore.exp,v
retrieving revision 1.4
diff -u -r1.4 bigcore.exp
--- bigcore.exp	27 Feb 2004 16:48:03 -0000	1.4
+++ bigcore.exp	12 Mar 2004 22:17:59 -0000
@@ -190,3 +190,7 @@
 
 check_heap next $next_heap
 check_heap prev $prev_heap
+
+# The generated core file uses a large amount of disk-space, so we
+# delete it now that we're done.
+remote_exec build "rm -f $corefile"

[RFA/testsuite] Some feedback about bigcore.exp...

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 962 bytes --]

Hello,

Just FYI, in case others may feel the same way?

We have now run this test pretty much on most of our Unix native
platforms, and have found that the bigcore.exp testcase is usually quite
stressful for the host where the testing is being conducted. For
instance, on sparc-solaris, the system ran out of virtual memory and
swap space, and started killing processes at random. It also requires a
very large amount of disk space to be available for the core file (2GB
on x86-linux). So I was told by other fellow machine users to please
stop running this test on our build machines.

One thing I would recommend is to delete the core file once the test is
finished. I had a testsuite run that got ruined because the core file
filled up all my disk, and left no space available for the rest of the
run...

2004-03-12  J. Brobecker  <brobecker@gnat.com>

        * gdb.base/bigcore.exp: Delete core file after test has completed.

Sounds reasonable?

-- 
Joel

[-- Attachment #2: bigcore.exp --]
[-- Type: text/plain, Size: 506 bytes --]

Index: bigcore.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/bigcore.exp,v
retrieving revision 1.4
diff -u -r1.4 bigcore.exp
--- bigcore.exp	27 Feb 2004 16:48:03 -0000	1.4
+++ bigcore.exp	12 Mar 2004 22:17:59 -0000
@@ -190,3 +190,7 @@
 
 check_heap next $next_heap
 check_heap prev $prev_heap
+
+# The generated core file uses a large amount of disk-space, so we
+# delete it now that we're done.
+remote_exec build "rm -f $corefile"

Re: [RFA/testsuite] Some feedback about bigcore.exp...

[Andrew Cagney]

> Hello,
> 
> Just FYI, in case others may feel the same way?
> 
> We have now run this test pretty much on most of our Unix native
> platforms, and have found that the bigcore.exp testcase is usually quite
> stressful for the host where the testing is being conducted. For
> instance, on sparc-solaris, the system ran out of virtual memory and
> swap space, and started killing processes at random. It also requires a
> very large amount of disk space to be available for the core file (2GB
> on x86-linux). So I was told by other fellow machine users to please
> stop running this test on our build machines.
> 
> One thing I would recommend is to delete the core file once the test is
> finished. I had a testsuite run that got ruined because the core file
> filled up all my disk, and left no space available for the rest of the
> run...
> 
> 2004-03-12  J. Brobecker  <brobecker@gnat.com>
> 
>         * gdb.base/bigcore.exp: Delete core file after test has completed.

No - it will mean throwing away testsuite information.  If a system is 
filling disk space with really large core files (as determined by du, 
not ls) then that system should have the test disabled -> no sparse core 
file support.

Andrew


> Sounds reasonable?
> 
> -- Joel
> 
> 
> 
> Index: bigcore.exp
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/gdb.base/bigcore.exp,v
> retrieving revision 1.4
> diff -u -r1.4 bigcore.exp
> --- bigcore.exp	27 Feb 2004 16:48:03 -0000	1.4
> +++ bigcore.exp	12 Mar 2004 22:17:59 -0000
> @@ -190,3 +190,7 @@
>  
>  check_heap next $next_heap
>  check_heap prev $prev_heap
> +
> +# The generated core file uses a large amount of disk-space, so we
> +# delete it now that we're done.
> +remote_exec build "rm -f $corefile"

Re: [RFA/testsuite] Some feedback about bigcore.exp...

[Andrew Cagney]

> Hello,
> 
> Just FYI, in case others may feel the same way?
> 
> We have now run this test pretty much on most of our Unix native
> platforms, and have found that the bigcore.exp testcase is usually quite
> stressful for the host where the testing is being conducted. For
> instance, on sparc-solaris, the system ran out of virtual memory and
> swap space, and started killing processes at random. It also requires a
> very large amount of disk space to be available for the core file (2GB
> on x86-linux). So I was told by other fellow machine users to please
> stop running this test on our build machines.
> 
> One thing I would recommend is to delete the core file once the test is
> finished. I had a testsuite run that got ruined because the core file
> filled up all my disk, and left no space available for the rest of the
> run...
> 
> 2004-03-12  J. Brobecker  <brobecker@gnat.com>
> 
>         * gdb.base/bigcore.exp: Delete core file after test has completed.

No - it will mean throwing away testsuite information.  If a system is 
filling disk space with really large core files (as determined by du, 
not ls) then that system should have the test disabled -> no sparse core 
file support.

Andrew


> Sounds reasonable?
> 
> -- Joel
> 
> 
> 
> Index: bigcore.exp
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/gdb.base/bigcore.exp,v
> retrieving revision 1.4
> diff -u -r1.4 bigcore.exp
> --- bigcore.exp	27 Feb 2004 16:48:03 -0000	1.4
> +++ bigcore.exp	12 Mar 2004 22:17:59 -0000
> @@ -190,3 +190,7 @@
>  
>  check_heap next $next_heap
>  check_heap prev $prev_heap
> +
> +# The generated core file uses a large amount of disk-space, so we
> +# delete it now that we're done.
> +remote_exec build "rm -f $corefile"