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.
*
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 t
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 s
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 t
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 receive
See also, https://bugs.launchpad.net/juju-core/+bug/1303787
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1304754
Title:
gccgo compiled binaries are killed by SEGV on 64k ppc64el kernel
6 matches
Mail list logo