9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Russ Cox <rsc@swtch.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] self inflicted gunshot wound
Date: Wed,  8 Apr 2009 11:48:52 +1000	[thread overview]
Message-ID: <dd6fe68a0904071848v3bbd48c1n9a3e8f02606d129d@mail.gmail.com> (raw)
In-Reply-To: <720178c0132334d0e892b679a8d0c84d@quanstro.net>

> 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


  reply	other threads:[~2009-04-08  1:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-07 14:16 erik quanstrom
2009-04-08  1:48 ` Russ Cox [this message]
2009-04-08  2:59   ` erik quanstrom
2009-04-08  3:33     ` Russ Cox
2009-04-08  3:36       ` erik quanstrom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dd6fe68a0904071848v3bbd48c1n9a3e8f02606d129d@mail.gmail.com \
    --to=rsc@swtch.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).