FWIW, my guess is that the reason this appears to be fixed when
dropping to a smaller pagesize is simply because you're exhausting the
stack more slowly. Given that it takes a long while reproduce with juju
(or, so I've been told), it does also beg the question if juju has a
slow memory leak.
**
Based on the fail, I took a look at how gccgo handles stacks. It relies
on the split stack feature in gold, which doesn't appear to be
implemented for ppc64.
Running one of the go recursion testcases (attached) shows what happens
when we run out of stack and don't have the split stack feature to
Thanks Anton, this is great debugging.
I tried the peano experiment on my -8 (4k) kernel and it failed as
expected.
I talked to the upstream who said that ./configure should detect that
-fsplit-stack isn't supported on PPC and fall back to giving each
goroutine a full stack.
I will investigate
Would it be possible for you to test the latest upstream kernel? Refer
to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest
v3.14 kernel[0].
If this bug is fixed in the mainline kernel, please add the following
tag 'kernel-fixed-upstream'.
If the mainline kernel does not fix
If the bug still exists with the latest mainline kernel, we can perform
a bisect to identify the fix that introduced this. However, if the
mainline kernel resolves this bug, we can perform a Reverse bisect to
identify the commit that fixes this.
** Tags added: performing-bisect
--
You received
See also, https://bugs.launchpad.net/juju-core/+bug/1303787
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1304754
Title:
gccgo compiled binaries are killed by SEGV on 64k ppc64el kernels
To manage
