Comment 1:

i'm afraid the reason is not that simple.
i straced profilesegv, and found out the thread handled several SIGPROF signals before
the one that triggered SIGSEGV.
4435  --- SIGPROF (Profiling timer expired) @ 0 (0) --- 
4435  rt_sigreturn(0x1)                 = 0 
4435  --- SIGPROF (Profiling timer expired) @ 0 (0) --- 
4435  rt_sigreturn(0x1)                 = 2 
4435  --- SIGPROF (Profiling timer expired) @ 0 (0) --- 
4435  rt_sigreturn(0x1)                 = -94133986
4435  --- SIGPROF (Profiling timer expired) @ 0 (0) --- 
4435  rt_sigreturn(0x1)                 = 2 
4435  --- SIGPROF (Profiling timer expired) @ 0 (0) --- 
4435  --- SIGSEGV (Segmentation fault) @ 0 (0) --- 
4434  +++ killed by SIGSEGV +++ 
4433  +++ killed by SIGSEGV +++ 
because the strace log is very small, I attached it.

Attachments:

1. strace.log (41566 bytes)

Comment 2:

finally, I've found the reason, it has nothing to do with signal masking (although we do
have a bug there, http://golang.org/cl/6297087/)
the signal occurred in runtime.memset, which clobbers r9 and r10;
I think we never anticipated that possibility (except kaib's TODO note in
memset_arm.s, but that only mentioned SIGSEGV triggered by memset itself).
any suggestions? should we fix memset/memmove to not clobber r9/r10 or
we block all signals in them?
@dfc, you have some improvements on these function, what do you think? can you
make memset/memmove not touching r9/r10?

Labels changed: added priority-soon, removed priority-triage.

Status changed to Accepted.

Comment 3:

The block copy uses
    MOVM.IA.W [R4-R11], (R(TO))
which is a 32-byte copy using 8 registers.
Is there a 16-byte form using 4 registers?
The simplest fix would be to stop using R8, R9, R10, and R11, and then make this
    MOVM.IA.W [R4-R7], (R(TO))
if that's an option.
Russ

Comment 4:

oh, movm.ia.w uses a bitmap for registers, so we can use any 8 registers.
i think we can use r12&r14(LR) instead of r9/r10, and still maintain the
32-byte copy efficiency.
i think we can use LR in leaf functions (provided we back it up on stack),
what do you think about this idea?

Comment 5:

Will using LR break tracebacks? It would be nice not to do that.
You could use R2 (TOE) if you saved it before the f32loop and
restored it afterward.
Russ

Comment 6:

http://golang.org/cl/6300043
Fixes r9/r10 during memset. I hadn't mailed it because it produced no measurable
improvement in performance.

Comment 7:

Brilliant diagnosis btw, thanks.

Comment 8:

I've confirmed avoiding r9/10 during memmove solves the problem
(http://golang.org/cl/6300096 _really_ not ready for submission). I'll continue
to try to find a nicer way to do memmove.

Comment 9:

Responding to comment #3, doing two back to back 16 byte moves, vs a single 32byte move
looks like it costs about 15% when the data fits in the cache.
pando(~/go/src/pkg/runtime) % ~/go/misc/benchcmp {old,new}.txt 
benchmark              old ns/op    new ns/op    delta
BenchmarkMemmove32           113          112   -0.88%
BenchmarkMemmove4K          1242         1437  +15.70%
BenchmarkMemmove64K        60473        68747  +13.68%
BenchmarkMemmove4M      28684690     28676750   -0.03%
BenchmarkMemmove64M    460833600    460650800   -0.04%
benchmark               old MB/s     new MB/s  speedup
BenchmarkMemmove32        282.05       284.38    1.01x
BenchmarkMemmove4K       3295.79      2849.69    0.86x
BenchmarkMemmove64K      1083.72       953.28    0.88x
BenchmarkMemmove4M        146.22       146.26    1.00x
BenchmarkMemmove64M       145.62       145.68    1.00x

Comment 10:

Here is an alternative proposal for memmove that avoids spilling r9/10 in favour of
spilling and reusing the start/end register during the block move section.
http://golang.org/cl/6305100
@minux: I could not make MOVM.IA.W [R4-R7,R11] style syntax work, possibly the 5a
assembler doesn't understand it.

Comment 11:

@dfc, you could use MOVM.IA.W [R11,R4-R7], (R0); note the register range is at the end
and only one register range is allowed. (we certainly could lift this restriction, but
do you
have any requirements for this flexibility?)

Comment 12:

I'm happy to keep specifying the register bitmap explicitly as I don't
think I'm going to be able to change the code to always generate 2
register sets let alone one.

Comment 13:

This issue was closed by revision e34079b.

Status changed to Fixed.