Launchpad has imported 7 comments from the remote bug at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60931.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
Hi Dave,
It does look like a page size issue. I submitted the following bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60931
** Bug watch added: GCC Bugzilla #60931
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60931
--
You received this bug notification because you are a member of Ubuntu
** Also affects: gcc via
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60931
Importance: Unknown
Status: Unknown
--
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 on
I've made some progress with these fails. A lot of the confusion is
around the way gccgo hooks the SEGV handler and attempts to backtrace
all goroutines (the code is in runtime_tracebackothers())
It does this by calling runtime_gogo() which temporarily switches to the
goroutine using
This doesn't explain why we failed in the first place however. Using
gdb, I have seen a couple of SEGVs in:
* 1Thread 0x3fffa8c447e0 (LWP 5562) jujud timerproc
(dummy=optimized out) at ../../../gcc/libgo/runtime/time.goc:217
ie:
f = (void*)t-fv-fn;
Perhaps a stale
On Wed, Apr 16, 2014 at 4:26 PM, Anton Blanchard an...@samba.org wrote:
I've made some progress with these fails. A lot of the confusion is
around the way gccgo hooks the SEGV handler and attempts to backtrace
all goroutines (the code is in runtime_tracebackothers())
It does this by calling
Hi Anton,
I've been looking at another angle via a different crash. I see a
crash if a child process gets a signal, which sort of reflects back on
the parent.
Are there any alignment requirements for signal handling on 64k kernels
?
Dave
On Wed, Apr 16, 2014 at 4:28 PM, Anton Blanchard
There shouldn't be any difference in terms of signal handling.
I've now seen a couple of failures in mongodb/TLS networking code:
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x38]
goroutine 16 [running]:
An excellent point. Timers are managed by a single goroutine and a
priority queue of events to wait on and channels to send the timer
event. It should be doable to write some code that stresses timers.
However I don't believe that SIGALARM is used, well at least not in gc
which most of the gccgo
Anton:
I've done some experiments with the peano.go test and confirmed that
gccgo on ppc is correctly configured to not use f-split-stack. It turns
out the peano.go can't pass without split stacks. On gccgo/ppc64 the
program crashes at a stack depth of
Program received signal SIGSEGV,
10 matches
Mail list logo
