From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
In-Reply-To: <720178c0132334d0e892b679a8d0c84d@quanstro.net>
References: <720178c0132334d0e892b679a8d0c84d@quanstro.net>
Date: Wed,  8 Apr 2009 11:48:52 +1000
Message-ID: <dd6fe68a0904071848v3bbd48c1n9a3e8f02606d129d@mail.gmail.com>
Subject: Re: [9fans] self inflicted gunshot wound
From: Russ Cox <rsc@swtch.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: d5b753f6-ead4-11e9-9d60-3106f5b1d025

> abort()+0x0 /sys/src/libc/9sys/abort.c:6
> plumbpackattr(attr=0x28b00)+0x126 /sys/src/libplumb/mesg.c:125
>        n=0x93
>        a=0x3e990
>        s=0x3a430
>        t=0x3a497

t is unlikely to be correct here; it would have been saved
at the last call to strlen but since then got +='ed with the result.

> acid: regs()
> PC      0x0000c80c abort  /sys/src/libc/9sys/abort.c:6
> SP      0x00068e78 ECODE 0x00000004 EFLAG 0x00000206
> CS      0x00000023 DS    0x0000001b SS  0x0000001b
> GS      0x0000001b FS    0x0000001b ES  0x0000001b
> TRAP    0x0000000e page fault
> AX      0x0003a4c3 BX   0x0003a4c6 CX   0x0003a430 DX   0x00000093
> DI      0x0003a4c7 SI   0x0003ea19 BP   0x0003e9f0

there's s+n in AX.  t is likely to be BX or DI, judging from the
pointer values; it has either written 3 or 4 bytes past the
end of the allocated section, which explains the abort.
you'd have to disassemble plumbpackattr to make sure.
it would be interesting to print *(*plumbpackattr:s\s)
to see if the string is corrupted.

> the interesting thing that happened at the
> time was that one of plumber's clients was
> off in the weeds waiting for something to
> happen.

i don't understand what you mean.
plumbers clients are always waiting for something
to happen.  the plumber's only job is to tell them
when it does.

i suspect the global buffer in plumbpackattr's quote.
if you had multiple threads running through
plumbpackattr at once, it might cause the kind of crash you saw.
all the ordinary plumbing is protected by the QLock named queue,
but it looks like maybe if you'd been writing the rules file
at exactly the same time, that might have triggered
a simultaneous plumbpackattr call.

i'd prefer to be sure before throwing a lock in plumbpackattr.

russ