Is there any way to verify if a Debian package has been built with this gccgo fix?
Procedure: I downloaded the 14.04 debian packages from: http://juju-ci.vapour.ws:8080/job/publish-revision/690/ These packages were built on stilson-07 which has the PPA and the fixed version of gccgo. Then I ran apt-get upgrade/update sudo dpkg -i *1.20.2* juju bootstrap -v -e local –debug juju deploy local:trusty/ubuntu juju ssh ubuntu/0 Segmentation fault on stilson-01: http://pastebin.ubuntu.com/7832678/ According to line 372 the dmesg output: http://paste.ubuntu.com/7832700/ This appears to be the same problem, the deb packages were not built with the fix. I am also able to reproduce this Segmentation fault on the CI machine stilson-06. http://pastebin.ubuntu.com/7836776/ The CI build machine has the toolchain-r PPA and the fixed level of gccgo: http://pastebin.ubuntu.com/7836812/ The dmesg output is attached. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gccgo-4.9 in Ubuntu. https://bugs.launchpad.net/bugs/1304754 Title: gccgo has issues when page size is not 4kB Status in The GNU Compiler Collection: Fix Released Status in “gcc-4.9” package in Ubuntu: Fix Released Status in “gccgo-4.9” package in Ubuntu: Invalid Status in “gcc-4.9” source package in Trusty: Invalid Status in “gccgo-4.9” source package in Trusty: In Progress Status in “gcc-4.9” source package in Utopic: Fix Released Status in “gccgo-4.9” source package in Utopic: Invalid 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/gcc/+bug/1304754/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
