Re: [9fans] Okay, who's been playing with the cheese wiz?

Re: [9fans] Okay, who's been playing with the cheese wiz?

[rog]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

> it's nice to have a wrapper that [...] recreates it on hangup

how does this work?
i couldn't see anything in the manual about this.

> if there were better notation,

well, i suppose if rc were modified to support open read-write,
mount <>{command} /mnt/xxx
would look slightly more logical (and reflect what's actually happening).

> also there's a lot to be said for defaults.

that's true.
but it's also nice to see the mount points actually named in the
script that sets them up, i think. (i always have to look in the manual
page to see whether it's  (e.g.) /n/tapefs or /mnt/tapefs...)

> there is one real problem, which is that the servers would all need to
> know to rfork(RFNAMEG) at start, so that they don't hold up their own
> service ref counts.

don't they have to do that currently anyway?

[-- Attachment #2: Type: message/rfc822, Size: 2262 bytes --]

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Okay, who's been playing with the cheese wiz?
Date: Mon, 10 Feb 2003 08:36:10 -0500
Message-ID: <6e01499f169b0756f8b2ff199514cee2@plan9.bell-labs.com>

srv -e serves execnet's original purpose now.
it's nice to have a wrapper that creates the service
if necessary, recreates it on hangup, and so on.

mount >{command} /mnt/xxx
strikes me as an idiom that is clumsy
at best.  every time i see it, it takes a few
minutes to remember why it works at all --
the syntax would have you believe that
the pipe would be open only for writing.
if there were better notation, you might
convince me.  also there's a lot to be said
for defaults.  there is one real problem, which
is that the servers would all need to know
to rfork(RFNAMEG) at start, so that they don't
hold up their own service ref counts.

Re: [9fans] Okay, who's been playing with the cheese wiz?

[Russ Cox]

> it's nice to have a wrapper that [...] recreates it on hangup
> how does this work?
> i couldn't see anything in the manual about this.

srv does this.  if you 9fs alice but /srv/alice is dead,
srv will redial it and post a new one.  that's the wrapper
i was talking about.  it's just nice to reuse extant
connections when possible.  nothing fancy like recover.

Re: [9fans] Okay, who's been playing with the cheese wiz?

[Russ Cox]

Nothing to do with porting libregexp.

Russ

Re: [9fans] Okay, who's been playing with the cheese wiz?

[Dan Cross]

> Rob and I believe that this and a couple of obscure
> related bugs are now fixed, in both acme and sam.

I just checked it a little bit ago; it is indeed fixed.  Thanks.

	- Dan C.

Re: [9fans] Okay, who's been playing with the cheese wiz?

[Sam]

Bugs found porting libregexp?

Sam

On Mon, 17 Feb 2003, Russ Cox wrote:

> > I've run into a couple of weird things recently.  First, I noticed that
> > acme was commiting suicide after I tried to delete everything in a window
> > using, ``Edit 1,$d'' and then tried to edit normally.  A stack trace for
> > that follows:
>
> Rob and I believe that this and a couple of obscure
> related bugs are now fixed, in both acme and sam.
>
> Russ
>

Re: [9fans] Okay, who's been playing with the cheese wiz?

[Russ Cox]

> I've run into a couple of weird things recently.  First, I noticed that
> acme was commiting suicide after I tried to delete everything in a window
> using, ``Edit 1,$d'' and then tried to edit normally.  A stack trace for
> that follows:

Rob and I believe that this and a couple of obscure
related bugs are now fixed, in both acme and sam.

Russ

Re: [9fans] Okay, who's been playing with the cheese wiz?

[Dan Cross]

> Rob and I fixed some other bugs in acme, but not
> near the code involved in your Edit 1,$d crash.
> I cannot reproduce this.

Hmm; it seems to be related to doing it in a Win window.  Maybe
it has to do with win being broken; it doesn't seem to affect other
windows.

> I gave up on execnet a long time ago.  It's clunky
> and not clear that the interface should work that
> way.  What do you use it for?  (I'm just curious.)
> Copy /386/bin/execnet off of sources and you'll
> be happy.

Thanks, that fixed execnet. I'm using it for dialing u9fs on a Unix
machine; for some reason, when I tried srv -e back in the day, it
didn't work.  Maybe I should investigate it again.

> It doesn't surprise me that win is broken.  I always
> forget to recompile it because it's not in the /sys/src
> tree.  rc: note: peterface is an artifact of an old lib9p
> bug that I must have reintroduced.  I will have a look.

Okay, thanks.

> I pushed the lib9p changes out on Friday and have
> been slowly recompiling binaries for sources as
> I know they're okay.  I'm going crazy trying to keep
> my laptop, emelie (our internal fs), and sources all
> in sync (ironic, I know).  You picked an unfortunate
> time to recompile the world.  ;-)
>
> Sorry for the trouble.

No problem; it seems I'm the one always causing trouble, anyway.  :-)

	- Dan C.

Re: [9fans] Okay, who's been playing with the cheese wiz?

[Russ Cox]

srv -e serves execnet's original purpose now.
it's nice to have a wrapper that creates the service
if necessary, recreates it on hangup, and so on.

mount >{command} /mnt/xxx
strikes me as an idiom that is clumsy
at best.  every time i see it, it takes a few
minutes to remember why it works at all --
the syntax would have you believe that
the pipe would be open only for writing.
if there were better notation, you might
convince me.  also there's a lot to be said
for defaults.  there is one real problem, which
is that the servers would all need to know
to rfork(RFNAMEG) at start, so that they don't
hold up their own service ref counts.

Re: [9fans] Okay, who's been playing with the cheese wiz?

[rog]

> I gave up on execnet a long time ago.  It's clunky
> and not clear that the interface should work that
> way.  What do you use it for?  (I'm just curious.)

for what it was used for, i couldn't see what was wrong with just
posting a named pipe to the command into /srv, assuming that the
command could serve 9p on its standard input.

in fact, it would seem to me to be a good idea to let all file server
commands serve 9p through stdin; then they can be mounted simply with:

mount >{command} /mnt/xxx

the command doesn't have to parse all those mount options or know
where it might be mounted, and you don't have to worry about
backgrounding it and then worrying whether it might not have mounted
in time.  (plus it's more versatile).

the original execnet stuff (assuming i understood what it was about)
could have been done with something like:

postsrv u9fs >{ssh ny 'u9fs -na none -u $USER -l $HOME/tmp/u9fs.log'}

(assuming the following command; maybe there is a similar command
somewhere else?):

/* postsrv.c */
#include <u.h>
#include <libc.h>

void main(int argc, char**argv)
{
	char buf[256];
	int fd, srvfd;
	if (argc != 3) {
		fprint(2, "usage: postsrv srvname file\n");
		exits("usage");
	}
	fd = open(argv[2], ORDWR);
	if (fd == -1) {
		fprint(2, "postsrv: cannot open %s: %r\n", argv[2]);
		exits("error");
	}
	snprint(buf, sizeof(buf), "/srv/%s", argv[1]);
	srvfd = create(buf, OWRITE, 0666);
	if (srvfd == -1) {
		fprint(2, "postsrv: cannot create %s: %r\n", buf);
		exits("error");
	}
	if (fprint(srvfd, "%d", fd) == -1) {
		fprint(2, "postsrv: cannot post %d: %r\n", fd);
		exits("error");
	}
}

Re: [9fans] Okay, who's been playing with the cheese wiz?

[okamoto]

> acme: bufread: internal error: '/lib/font/bit/lucidasans/lsr.14.0' does not exist

I saw this error message through our developement.
I thought it may concern with thread(2), not intended different thread was
attacked?   Probably, I'm say something fool...

kenji

Re: [9fans] Okay, who's been playing with the cheese wiz?

[rob pike, esq.]

The win problem has been fixed, as Russ mentioned.

The two acme things you report are both the same; the
stack trace corresponds to the error message you report
from bufread.  (The %r that results from calling error() in
bufread is worthless; the error is totally internal.)

There's a good chance you have a real bug; I've seen
stacks like this before and have tracked them down
successfully.  I can't reproduce your symptom, though.

There is a slim chance it's related to a recent change to
acme regarding how the undo sequence number is
maintained. Slim.

-rob

Re: [9fans] Okay, who's been playing with the cheese wiz?

[Russ Cox]

Rob and I fixed some other bugs in acme, but not
near the code involved in your Edit 1,$d crash.
I cannot reproduce this.

I changed lib9p to do a few more checks that the
client code is behaving, and your execnet crash
shows that lib9p thinks execnet is not behaving.
It turns out that actually lib9p is not behaving -- I was
trying to clean up this particular detail (whether a
walk function should set both fid->qid and *qid),
because it always confuses me, and I got confused.
I just put out a new srv.c that makes reasonable
demands of the clients.

I gave up on execnet a long time ago.  It's clunky
and not clear that the interface should work that
way.  What do you use it for?  (I'm just curious.)
Copy /386/bin/execnet off of sources and you'll
be happy.

It doesn't surprise me that win is broken.  I always
forget to recompile it because it's not in the /sys/src
tree.  rc: note: peterface is an artifact of an old lib9p
bug that I must have reintroduced.  I will have a look.

I pushed the lib9p changes out on Friday and have
been slowly recompiling binaries for sources as
I know they're okay.  I'm going crazy trying to keep
my laptop, emelie (our internal fs), and sources all
in sync (ironic, I know).  You picked an unfortunate
time to recompile the world.  ;-)

Sorry for the trouble.

Russ

[9fans] Okay, who's been playing with the cheese wiz?

[Dan Cross]

I've run into a couple of weird things recently.  First, I noticed that
acme was commiting suicide after I tried to delete everything in a window
using, ``Edit 1,$d'' and then tried to edit normally.  A stack trace for
that follows:

acid: lstk()
At pc:0x00039bc1:abort /sys/src/libc/9sys/abort.c:6
abort() /sys/src/libc/9sys/abort.c:6
	called from error+0x33 /sys/src/cmd/acme/util.c:55
error(s=0x000400b1) /sys/src/cmd/acme/util.c:51
	called from bufread+0xca /sys/src/cmd/acme/buff.c:287
bufread(b=0x000941c0,q0=0x00000254,n=0x00000001,s=0x00087b96) /sys/src/cmd/acme/buff.c:280
	called from textreadc+0x46 /sys/src/cmd/acme/text.c:486
	m=0x0003f878
textreadc(q=0x00000254,t=0x00093ed0) /sys/src/cmd/acme/text.c:478
	called from textbacknl+0x62 /sys/src/cmd/acme/text.c:1153
	r=0xc37f0000
textbacknl(n=0x00000012,p=0x00000255,t=0x00093ed0) /sys/src/cmd/acme/text.c:1139
	called from textshow+0xc3 /sys/src/cmd/acme/text.c:809
	i=0x00000011
	j=0x0000007f
textshow(q0=0x00000256,t=0x00093ed0,doselect=0x00000001,q1=0x00000256) /sys/src/cmd/acme/text.c:789
	called from texttype+0xf9 /sys/src/cmd/acme/text.c:553
texttype(t=0x00093ed0,r=0x0000000a) /sys/src/cmd/acme/text.c:521
	called from wintype+0x18 /sys/src/cmd/acme/wind.c:274
	nnb=0x00093de0
	q1=0x000003ad
	q0=0x0001dc38
	i=0x00093df0
	nb=0x0001dbe0
	u=0x0002db50
	n=0x00000002
wintype(t=0x00093ed0,r=0x0000000a,w=0x00093de0) /sys/src/cmd/acme/wind.c:270
	called from rowtype+0xce /sys/src/cmd/acme/rows.c:274
	i=0x00000000
rowtype(row=0x00048720,p=0x000003ad,r=0x0000000a) /sys/src/cmd/acme/rows.c:257
	called from keyboardthread+0xb2 /sys/src/cmd/acme/acme.c:386
	t=0x00093ed0
	w=0x00093de0
keyboardthread() /sys/src/cmd/acme/acme.c:351
	called from launcher386+0x10 /sys/src/libthread/386.c:10
	r=0xfee1000a
	timer=0x00098008
	t=0x00093df4
launcher386(arg=0x00000000,f=0x00001f99) /sys/src/libthread/386.c:7
	called from 0xfefefefe ?file?:0
acid:

I was away last week, so thought perhaps this was a known bug that had
been fixed elsewhere.  When I got back, I noticed a bunch of acme updates,
so I rebuilt the system to try and get everything to work again, but
now execnet dies with:

fid/qid mismatch in walk1 functionexecnet 223: suicide: sys: trap: fault read addr=0x0 pc=0x00008154

A stack trace follows:

acid: lstk()
At pc:0x00008154:abort /sys/src/libc/9sys/abort.c:6
abort() /sys/src/libc/9sys/abort.c:6
	called from oldwalk1+0x5e /sys/src/lib9p/srv.c:288
oldwalk1(arg=0x0001813c,fid=0x00036690,name=0x00028cd2) /sys/src/lib9p/srv.c:273
	called from walkandclone+0xb6 /sys/src/lib9p/srv.c:151
	qid=0x00000001
walkandclone(clone=0x0000f71d,r=0x00036250,arg=0x0001813c,walk1=0x0000f68d) /sys/src/lib9p/srv.c:131
	called from swalk+0x131 /sys/src/lib9p/srv.c:334
	i=0x00000000
swalk(srv=0x0001813c,r=0x00036250) /sys/src/lib9p/srv.c:303
	called from srv+0x182 /sys/src/lib9p/srv.c:711
srv(srv=0x0001813c) /sys/src/lib9p/srv.c:692
	called from _post2+0x47 /sys/src/lib9p/_post.c:39
_post2(v=0x0001813c) /sys/src/lib9p/_post.c:31
	called from launcher386+0x10 /sys/src/libthread/386.c:10
	s=0x0001813c
launcher386(arg=0x0001813c,f=0x000125dd) /sys/src/libthread/386.c:7
	called from 0xfefefefe ?file?:0
acid:

I thought that was pretty bizarre.  Anyway, acme continues to crash,
and now I get this, as well:

acme: bufread: internal error: '/lib/font/bit/lucidasans/lsr.14.0' does not exist

I don't recall having seen that previously.  Also, `win' is behaving
pretty bizarrely; if I type a command in a ``win'' window, I get:
``rc: note: '', a Peter face, the rc dies, and the window hangs.

This is using the latest code from sources; I pulled last night and
rebuilt everything: userland and the kernel, this morning.

I've had a really really terrible two and a half weeks and so havn't
looked into any of this myself.  Anyone else have any ideas?

	- Dan C.