diff mbox

Too much memory in chan/select2.go used

Message ID mcrr4y4qzgj.fsf@dhcp-172-18-216-180.mtv.corp.google.com
State New
Headers show

Commit Message

Ian Lance Taylor Feb. 9, 2012, 6:43 a.m. UTC 
Uros Bizjak <ubizjak@gmail.com> writes:

> Some more debugging reveal the difference between alpha and x86_64.
> Alpha does not implement split stacks, so soon after
> "runtime.MemStats.Alloc = 0" line, we allocate exactly 2MB fake stack
> via:

Thanks for tracking this down.

> So, short of XFAILing the test on non-split stack targets, I have no
> other idea how to handle this testcase failure.

I thought about it for a while, and I can't think of any better approach
than to skip this test case.  A simple xfail doesn't work because it
xfails the compilation of the test case rather than the execution,
leading to an XPASS and a FAIL.

I have committed this patch.

Ian


2012-02-08  Ian Lance Taylor  <iant@google.com>

	* go.test/go-test.exp (go-gc-tests): Don't run chan/select2.go on
	systems which don't support -fsplit-stack.

Comments

Uros Bizjak Feb. 9, 2012, 11:17 a.m. UTC | #1 
On Thu, Feb 9, 2012 at 7:43 AM, Ian Lance Taylor <iant@google.com> wrote:
> Uros Bizjak <ubizjak@gmail.com> writes:
>
>> Some more debugging reveal the difference between alpha and x86_64.
>> Alpha does not implement split stacks, so soon after
>> "runtime.MemStats.Alloc = 0" line, we allocate exactly 2MB fake stack
>> via:
>
> Thanks for tracking this down.
>
>> So, short of XFAILing the test on non-split stack targets, I have no
>> other idea how to handle this testcase failure.
>
> I thought about it for a while, and I can't think of any better approach
> than to skip this test case.  A simple xfail doesn't work because it
> xfails the compilation of the test case rather than the execution,
> leading to an XPASS and a FAIL.

Thanks!

BTW: I'd like to point out that we can use go-execute-xfail in this
case, so the case is compiled but is known to fail execution for some
reason.

Uros.
Ian Lance Taylor Feb. 9, 2012, 5:44 p.m. UTC | #2 
Uros Bizjak <ubizjak@gmail.com> writes:

> BTW: I'd like to point out that we can use go-execute-xfail in this
> case, so the case is compiled but is known to fail execution for some
> reason.

Thanks, I didn't know about that one.

I think I'll leave it as is for now because I'm treating stack.go the
same way, and stack.go does sometimes pass even without -fsplit-stack.

Ian
diff mbox

Patch

Index: gcc/testsuite/go.test/go-test.exp
===================================================================
--- gcc/testsuite/go.test/go-test.exp	(revision 184032)
+++ gcc/testsuite/go.test/go-test.exp	(working copy)
@@ -33,6 +33,7 @@ 
 
 load_lib go-dg.exp
 load_lib go-torture.exp
+load_lib target-supports.exp
 
 # Compare two files
 proc filecmp { file1 file2 testname } {
@@ -329,6 +330,15 @@  proc go-gc-tests { } {
 	    continue
 	}
 
+	if { [file tail $test] == "select2.go" && \
+		 ! [check_effective_target_split_stack] } {
+	    # chan/select2.go fails on targets without split stack,
+	    # because they allocate a large stack segment that blows
+	    # out the memory calculations.
+	    untested $name
+	    continue
+	}
+
 	set fd [open $test r]
 
 	set lines_ok 1