kernel-packages team mailing list archive

[Adam Conrad <adconrad@xxxxxxx>]

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.

** Package changed: linux (Ubuntu) => gccgo-4.9 (Ubuntu)

** Changed in: gccgo-4.9 (Ubuntu)
       Status: Incomplete => Confirmed

** Summary changed:

- gccgo compiled binaries are killed by SEGV on 64k ppc64el kernels
+ gccgo on ppc64el using split stacks when not supported

** Tags removed: kernel-da-key performing-bisect

-- 
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 on ppc64el using split stacks when not supported

Status in “gccgo-4.9” package in Ubuntu:
  Confirmed

Bug description:
  On kernels 3.13-18 and 3.13-23 (there may be others) the kernel is
  killing gccgo compiled binaries

  [18519.444748] jujud[19277]: bad frame in setup_rt_frame:
  0000000000000000 nip 0000000000000000 lr 0000000000000000
  [18519.673632] init: juju-agent-ubuntu-local main process (19220)
  killed by SEGV signal
  [18519.673651] init: juju-agent-ubuntu-local main process ended, respawning

  In powerpc/kernel/signal_64.c:

  sys_rt_sigreturn is jumping to the badframe: label and executing an
  unconditional force_sigsegv which is delivered to the userland
  process. Like C++, gccgo tries to decode SIGSEGV as a nil pointer
  access and blame some random function that happened to be the top
  stack frame.

  Reverting to the 3.13-08 kernel appears to resolve the issue which
  (weakly) points the finger at the recent switch to 64k pages.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gccgo-4.9/+bug/1304754/+subscriptions