Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [RFC] XFAIL bigcore.exp on some GNU/Linux targets
@ 2004-04-17 21:42 Daniel Jacobowitz
  2004-04-21 14:55 ` Andrew Cagney
  0 siblings, 1 reply; 4+ messages in thread
From: Daniel Jacobowitz @ 2004-04-17 21:42 UTC (permalink / raw)
  To: gdb-patches

This implements the suggestion I made in PR external/1568: if the core file
is too small to contain the heap as a sparse file, xfail.  This does assume
thtat the OS will use sparse files to implement sparse coredumps, rather
than using multiple PT_LOAD segments.  Seems to be right so far.

Thoughts?  It's a little hackish, but I don't consider it acceptable to just
leave the tests failing on "broken" Linux kernels, especially since there
are no publicly available "fixed" kernels to my knowledge (at least, not
from the normal kernel.org distributions - I don't know if any vendors fixed
this in their public distributions.  I'm guessing it works on RHEL3 and
maybe Fedora).

The comment about expect_out not working in gdb_test_multiple is out of
date; I fixed it a month or so ago, so use gdb_test_multiple here also.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2004-04-17  Daniel Jacobowitz  <drow@mvista.com>

	PR external/1568
	* gdb.base/bigcore.exp: Check the size of the dumped core file.
	XFAIL if it is too small.

Index: bigcore.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/bigcore.exp,v
retrieving revision 1.5
diff -u -p -r1.5 bigcore.exp
--- bigcore.exp	9 Apr 2004 13:37:38 -0000	1.5
+++ bigcore.exp	17 Apr 2004 21:36:59 -0000
@@ -105,9 +105,72 @@ gdb_test "tbreak $print_core_line"
 gdb_test continue ".*print_string.*"
 gdb_test next ".*0 = 0.*"
 
+# Traverse part of bigcore's linked list of memory chunks, finding the total
+# size.  Note that we use GDB to do the math; TCL is not reliable with
+# extremely large integers.
+
+proc heap_size { } {
+    global gdb_prompt
+    global expect_out
+    set test "find heap size"
+    set lim 0
+    gdb_test "set \$size = 0" ""
+    gdb_test_multiple "print heap.next" "$test" {
+	-re " = \\(struct list \\*\\) 0x0.*$gdb_prompt $" {
+	    pass "$test"
+	}
+	-re " = \\(struct list \\*\\) (0x\[0-9a-f\]*).*$gdb_prompt $" {
+	    if { $lim >= 50 } {
+		pass "$test (stop at $lim)"
+	    } else {
+		incr lim
+		gdb_test "set \$size = \$size + \$.size" ""
+		send_gdb "print \$.next\n"
+		exp_continue
+	    }
+	}
+	-re ".*$gdb_prompt $" {
+	    fail "$test (entry $lim)"
+	}
+	timeout {
+	    fail "$test (timeout)"
+	}
+    }
+    gdb_test_multiple "print \$size" "print \$size" {
+	-re " = (\[0-9\]*)\r\n$gdb_prompt $" {
+	    set size $expect_out(1,string)
+	    pass "print \$size"
+	}
+    }
+    return $size;
+}
+
+set total_size [heap_size]
+
+# Check that the corefile is plausibly large enough.  We're trying to
+# detect the case where the operating system has truncated the file
+# just before signed wraparound.  TCL, unfortunately, has a similar
+# problem - so use catch.  It can handle the "bad" size but not necessarily
+# the "good" one.  And we must use GDB for the comparison, similarly.
+
+if {[catch {file size $corefile} core_size] == 0} {
+    set core_ok 0
+    gdb_test_multiple "print $total_size < $core_size" "check core size" {
+	-re " = 1\r\n$gdb_prompt $" {
+	    pass "check core size"
+	    set core_ok 1
+	}
+	-re " = 0\r\n$gdb_prompt $" {
+	    xfail "check core size (system does not support large corefiles)"
+	}
+    }
+    if {$core_ok == 0} {
+	return 0
+    }
+}
+
 # Traverse part of bigcore's linked list of memory chunks (forward or
-# backward), saving each chunk's address.  I don't know why but
-# expect_out didn't work with gdb_test_multiple.
+# backward), saving each chunk's address.
 
 proc extract_heap { dir } {
     global gdb_prompt
@@ -115,8 +178,7 @@ proc extract_heap { dir } {
     set heap ""
     set test "extract ${dir} heap"
     set lim 0
-    send_gdb "print heap.${dir}\n"
-    gdb_expect {
+    gdb_test_multiple "print heap.${dir}" "$test" {
 	-re " = \\(struct list \\*\\) 0x0.*$gdb_prompt $" {
 	    pass "$test"
 	}


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFC] XFAIL bigcore.exp on some GNU/Linux targets
  2004-04-17 21:42 [RFC] XFAIL bigcore.exp on some GNU/Linux targets Daniel Jacobowitz
@ 2004-04-21 14:55 ` Andrew Cagney
  2004-04-21 14:59   ` Daniel Jacobowitz
  0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cagney @ 2004-04-21 14:55 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: gdb-patches

Why not ask the program the heap size?  it's in total_allocated, just 
make that a static.

> +# Traverse part of bigcore's linked list of memory chunks, finding the total
> +# size.  Note that we use GDB to do the math; TCL is not reliable with
> +# extremely large integers.
> +
> +proc heap_size { } {
> +    global gdb_prompt
> +    global expect_out
> +    set test "find heap size"
> +    set lim 0
> +    gdb_test "set \$size = 0" ""
> +    gdb_test_multiple "print heap.next" "$test" {
> +	-re " = \\(struct list \\*\\) 0x0.*$gdb_prompt $" {
> +	    pass "$test"
> +	}
> +	-re " = \\(struct list \\*\\) (0x\[0-9a-f\]*).*$gdb_prompt $" {
> +	    if { $lim >= 50 } {
> +		pass "$test (stop at $lim)"
> +	    } else {
> +		incr lim
> +		gdb_test "set \$size = \$size + \$.size" ""
> +		send_gdb "print \$.next\n"
> +		exp_continue
> +	    }
> +	}
> +	-re ".*$gdb_prompt $" {
> +	    fail "$test (entry $lim)"
> +	}
> +	timeout {
> +	    fail "$test (timeout)"
> +	}
> +    }
> +    gdb_test_multiple "print \$size" "print \$size" {
> +	-re " = (\[0-9\]*)\r\n$gdb_prompt $" {
> +	    set size $expect_out(1,string)
> +	    pass "print \$size"
> +	}
> +    }
> +    return $size;
> +}
> +


Andrew


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFC] XFAIL bigcore.exp on some GNU/Linux targets
  2004-04-21 14:55 ` Andrew Cagney
@ 2004-04-21 14:59   ` Daniel Jacobowitz
  2004-05-10 16:49     ` Daniel Jacobowitz
  0 siblings, 1 reply; 4+ messages in thread
From: Daniel Jacobowitz @ 2004-04-21 14:59 UTC (permalink / raw)
  To: Andrew Cagney; +Cc: gdb-patches

On Tue, Apr 20, 2004 at 01:26:45PM -0400, Andrew Cagney wrote:
> Why not ask the program the heap size?  it's in total_allocated, just 
> make that a static.

Duh.  I'll update the patch to do that before I check it in.

> 
> >+# Traverse part of bigcore's linked list of memory chunks, finding the 
> >total
> >+# size.  Note that we use GDB to do the math; TCL is not reliable with
> >+# extremely large integers.
> >+
> >+proc heap_size { } {
> >+    global gdb_prompt
> >+    global expect_out
> >+    set test "find heap size"
> >+    set lim 0
> >+    gdb_test "set \$size = 0" ""
> >+    gdb_test_multiple "print heap.next" "$test" {
> >+	-re " = \\(struct list \\*\\) 0x0.*$gdb_prompt $" {
> >+	    pass "$test"
> >+	}
> >+	-re " = \\(struct list \\*\\) (0x\[0-9a-f\]*).*$gdb_prompt $" {
> >+	    if { $lim >= 50 } {
> >+		pass "$test (stop at $lim)"
> >+	    } else {
> >+		incr lim
> >+		gdb_test "set \$size = \$size + \$.size" ""
> >+		send_gdb "print \$.next\n"
> >+		exp_continue
> >+	    }
> >+	}
> >+	-re ".*$gdb_prompt $" {
> >+	    fail "$test (entry $lim)"
> >+	}
> >+	timeout {
> >+	    fail "$test (timeout)"
> >+	}
> >+    }
> >+    gdb_test_multiple "print \$size" "print \$size" {
> >+	-re " = (\[0-9\]*)\r\n$gdb_prompt $" {
> >+	    set size $expect_out(1,string)
> >+	    pass "print \$size"
> >+	}
> >+    }
> >+    return $size;
> >+}
> >+
> 
> 
> Andrew
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFC] XFAIL bigcore.exp on some GNU/Linux targets
  2004-04-21 14:59   ` Daniel Jacobowitz
@ 2004-05-10 16:49     ` Daniel Jacobowitz
  0 siblings, 0 replies; 4+ messages in thread
From: Daniel Jacobowitz @ 2004-05-10 16:49 UTC (permalink / raw)
  To: gdb-patches

On Wed, Apr 21, 2004 at 10:59:51AM -0400, Daniel Jacobowitz wrote:
> On Tue, Apr 20, 2004 at 01:26:45PM -0400, Andrew Cagney wrote:
> > Why not ask the program the heap size?  it's in total_allocated, just 
> > make that a static.
> 
> Duh.  I'll update the patch to do that before I check it in.

Done like so; checked in.  This replaces one PASS and two FAILs on an
unpatched i386-linux target with a single XFAIL.

-- 
Daniel Jacobowitz

2004-05-10  Daniel Jacobowitz  <dan@debian.org>

	PR external/1568
	* gdb.base/bigcore.exp: Check the size of the dumped core file.
	XFAIL if it is smaller than bytes_allocated.
	* gdb.base/bigcore.c (bytes_allocated): Make static and unsigned.
	(main): Make chunks_allocated unsigned.  Correct comment.

Index: bigcore.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/bigcore.exp,v
retrieving revision 1.5
diff -u -p -r1.5 bigcore.exp
--- bigcore.exp	9 Apr 2004 13:37:38 -0000	1.5
+++ bigcore.exp	10 May 2004 16:27:24 -0000
@@ -105,9 +105,30 @@ gdb_test "tbreak $print_core_line"
 gdb_test continue ".*print_string.*"
 gdb_test next ".*0 = 0.*"
 
+# Check that the corefile is plausibly large enough.  We're trying to
+# detect the case where the operating system has truncated the file
+# just before signed wraparound.  TCL, unfortunately, has a similar
+# problem - so use catch.  It can handle the "bad" size but not necessarily
+# the "good" one.  And we must use GDB for the comparison, similarly.
+
+if {[catch {file size $corefile} core_size] == 0} {
+    set core_ok 0
+    gdb_test_multiple "print bytes_allocated < $core_size" "check core size" {
+	-re " = 1\r\n$gdb_prompt $" {
+	    pass "check core size"
+	    set core_ok 1
+	}
+	-re " = 0\r\n$gdb_prompt $" {
+	    xfail "check core size (system does not support large corefiles)"
+	}
+    }
+    if {$core_ok == 0} {
+	return 0
+    }
+}
+
 # Traverse part of bigcore's linked list of memory chunks (forward or
-# backward), saving each chunk's address.  I don't know why but
-# expect_out didn't work with gdb_test_multiple.
+# backward), saving each chunk's address.
 
 proc extract_heap { dir } {
     global gdb_prompt
@@ -115,8 +136,7 @@ proc extract_heap { dir } {
     set heap ""
     set test "extract ${dir} heap"
     set lim 0
-    send_gdb "print heap.${dir}\n"
-    gdb_expect {
+    gdb_test_multiple "print heap.${dir}" "$test" {
 	-re " = \\(struct list \\*\\) 0x0.*$gdb_prompt $" {
 	    pass "$test"
 	}
Index: bigcore.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/bigcore.c,v
retrieving revision 1.2
diff -u -p -r1.2 bigcore.c
--- bigcore.c	16 Feb 2004 18:49:09 -0000	1.2
+++ bigcore.c	10 May 2004 16:27:24 -0000
@@ -117,6 +117,8 @@ struct list
 static struct list dummy;
 static struct list heap = { &dummy, &dummy };
 
+static unsigned long bytes_allocated;
+
 int
 main ()
 {
@@ -151,14 +153,13 @@ main ()
      each section.  The linking ensures that some, but not all, the
      memory is allocated.  NB: Some kernels handle this efficiently -
      only allocating and writing out referenced pages leaving holes in
-     the file for unreferend pages - while others handle this poorly -
-     writing out all pages including those that wern't referenced.  */
+     the file for unmodified pages - while others handle this poorly -
+     writing out all pages including those that weren't modified.  */
 
   print_string ("Alocating the entire heap ...\n");
   {
     size_t chunk_size;
-    long bytes_allocated = 0;
-    long chunks_allocated = 0;
+    unsigned long chunks_allocated = 0;
     /* Create a linked list of memory chunks.  Start with
        MAX_CHUNK_SIZE blocks of memory and then try allocating smaller
        and smaller amounts until all (well at least most) memory has


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2004-05-10 16:49 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-04-17 21:42 [RFC] XFAIL bigcore.exp on some GNU/Linux targets Daniel Jacobowitz
2004-04-21 14:55 ` Andrew Cagney
2004-04-21 14:59   ` Daniel Jacobowitz
2004-05-10 16:49     ` Daniel Jacobowitz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox