9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* exec(2) problem?
@ 1996-02-06 12:08 forsyth
  0 siblings, 0 replies; 2+ messages in thread
From: forsyth @ 1996-02-06 12:08 UTC (permalink / raw)


periodically one of the larger PC cpu servers here goes into an odd state.
a newly typed command hangs, as do subsequent commands, until the
first is interrupted, producing:

ls 17280: suicide: invalid address 0xb532 in sys call pc=0xe622
ls 17280: suicide: bad address in notify

it isn't just ls, and regardless of the actual command, the invalid
address and pc= are always the same, which i found rather eerie.
ps shows a Broken process with a 16Mbyte stack.
after this has happened once, it tends to happen frequently until
it affects something critical, and a reboot is required.

it turns out that 0xe622 is an address in /bin/rc.
term% db /bin/rc
386 binary
#0xe622?i
exec+#7?        RET
exec?i
exec?           MOVL	$#7,AX
exec+#5?        INTB	$#40
exec+#7?        RET

i'm fairly sure the problem arises when the process has committed
to Exec in sysexec in /sys/src/9/port/sysproc.c, but receives a note,
for instance during the tsleep in the resrcwait in imageattach.
if i delayed interrupting a hung ls, ^t^tp on the console
showed the hung process in Exec state in imagereclaim.
indeed, attachimage is probably the only chance for notes to
strike sysexec, since the close() and fdclose() calls
have got their own error handling.  

on my server, it probably runs out of images because conf.nimage is only 50.
it's easy to increase that to decrease the chance of this happening,
but that only addresses the symptom.

if i'm right about the source of the problem, what's the best fix?
defer notes after committing to the exec?  keep the process in
attachimage() until it succeeds?






^ permalink raw reply	[flat|nested] 2+ messages in thread

* exec(2) problem?
@ 1996-02-06  9:57 philw
  0 siblings, 0 replies; 2+ messages in thread
From: philw @ 1996-02-06  9:57 UTC (permalink / raw)


It's a problem, imagereclaim should not call sleep.
change segment.c:228 from resrcwait(0) to sched().
This will prevent races cleaning the cache but
still allow things to proceed. I looked at the
other potentially sleeping things (close, fdclose)
and they seem ok because there is a waserror
on close which prevents the error from propagating
back to exec.

Diff's from the CD:

diff /n/juke/plan_9/sys/src/9/port/segment.c /sys/src/9/port:

228c228
< 		resrcwait(0);
---
> 		sched();






^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~1996-02-06 12:08 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1996-02-06 12:08 exec(2) problem? forsyth
  -- strict thread matches above, loose matches on Subject: below --
1996-02-06  9:57 philw

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).