I've seen this before, although by now I've seen so many errors crop
up that I can't recall them all.
>> === RUN TestErrors-2
>> template.test 289408: suicide: sys: floating point in note handler
>> pc=0x0001e9c7
>> exit status: 'template.test 289408: sys: floating point in note
>> handler pc=0x0001e9c7'
>> FAIL html/template 0.213s
>
> acid: stk()
> runtime.memmove(to=0x106dd000,fr=0x30887660,n=0x2c)+0x107
> /usr/glenda/src/go/src/pkg/runtime/memmove_386.s:145
> runtime.sighandler(s=0x30887660,v=0x308876e4,gp=0x106d31b0)+0x126
> /usr/glenda/src/go/src/pkg/runtime/os_plan9_386.c:67
> runtime.sigtramp(ureg=0x30887660,note=0x106d31b0)+0x44
> /usr/glenda/src/go/src/pkg/runtime/sys_plan9_386.s:161
> 0x308876e4 ?file?:0
> acid:
I am surprised, but also relieved that we have a resproducible mistake
outside the run.rc scope. We can focus on that.
I'm hoping cinap, with his in-depth knowledge of the kernel, can shed
some light here. It does look as if we have some error in the
handling of syscalls or notes, although I already mentioned I expected
a note to a process that had received a floating point exception
rather than a floating point exception in a note handler.
In my most recent copy of src/go/src/pkg/runtime/sys_plan9_386.s line
161 is a get_tls(BX), on return from sighandler(). Get_tls on the 386
resolves to
MOVL _tos(SB),r // zasm_plan9_386.h:8
so unless SB is way off, it does not seem to be a problem. I'd lay my
bets on sighandler() (so_plan9_386.c:28), but I am not comfortable
digging in there.
++L
