From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <1254af8db321f876dc44170675d6df34@proxima.alt.za> To: 9fans@9fans.net Date: Sat, 25 May 2013 07:50:00 +0200 From: lucio@proxima.alt.za In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Plan 9 Go 386 Topicbox-Message-UUID: 5bacd14a-ead8-11e9-9d60-3106f5b1d025 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