From: ori@eigenstate.org
To: 9front@9front.org
Subject: Re: [9front] acme: suicide when using upas/Mail
Date: Mon, 09 Oct 2023 17:50:38 -0400 [thread overview]
Message-ID: <001381913807BCD917D0F119B18A8060@eigenstate.org> (raw)
In-Reply-To: <0981F18AF2B7A02177B62E8AE4FF2874@smtp.pobox.com>
Quoth unobe@cpan.org:
> Sorry, I misunderstood what you were asking.
>
> I already deleted the window, restarting acme. I thought I only
> needed the lstk() in general, but I'll keep note of that for the
> future.
>
> Sorry for not having enough info (unless it's somewhere available
> under /proc/$pid/), and wasting your time.
no, you're good; precision is important, though -- the main thing
is that to debug, confirming that there was no other error after
the ': ', and therefore that for whatever reason, the temp file
was cut short.
If that's the case, the question is *what* temp file, because I
dont' think any of the mail windows should have a temp file.
Also, the gold standard is a snap(1) of the broken proc, but
beware that if there's any sensitive information in that, it will
be included.
>
> Quoth ori@eigenstate.org:
> > Quoth unobe@cpan.org:
> > > read error from temp file
> >
> > Are you sure? The code says:
> >
> > if(nr <= 0)
> > error("read error from temp file");
> >
> > and error does:
> >
> > fprint(2, "acme: %s: %r\n", s);
> >
> >
> > so at minimum, I'd expect the full error to start with 'acme:',
> > and a second ':' after "read error from temp file". Those are
> > both bits of information that are useful to match things up
> > with what happened.
> >
> > If there's an empty error string, which is printed by the '%r'
> > in error(), that means we got the only possible non-error
> > condition reading the temp file, an EOF (r == 0). I don't
> > know why we'd get that, but it leads down a different path
> > to investigate than a disk read error.
> >
> > > Quoth ori@eigenstate.org:
> > > > what's the exact error? this is acme suiciding after a pread() fails,
> > > > and the errstr says why.
> > > > '
> > > > Quoth unobe@cpan.org:
> > > > > Has anyone come across acme suicide not being able to read a temporary
> > > > > file? My HEAD is slightly behind:
> > > > > Hash: a327175a3c01d18e3e4c061ce4579cc420ee3561
> > > > > Author: cinap_lenrek <cinap_lenrek@felloff.net>
> > > > > Date: Sat Sep 30 10:06:58 -0700 2023
> > > > >
> > > > > I thought there might have recent work in caching for Mail, but a
> > > > > quick scan of the git/log didn't bring up any commit. upas/Mail was
> > > > > the only program I was running in acme. Here's the lstk() output:
> > > > >
> > > > > cpu% acid 1486111
> > > > > /proc/1486111/text:amd64 plan 9 executable
> > > > > /sys/lib/acid/port
> > > > > /sys/lib/acid/amd64
> > > > > acid: lstk()
> > > > > abort()+0x0 /sys/src/libc/9sys/abort.c:6
> > > > > error()+0x2f /sys/src/cmd/acme/util.c:55
> > > > > diskread(d=0x448f80,b=0x454d60,n=0x36d4,r=0x497ef0)+0xa6 /sys/src/cmd/acme/disk.c:138
> > > > > p=0x497ef0
> > > > > tot=0x203f6700000000
> > > > > nr=0xffffffff
> > > > > setcache(q0=0x0,b=0x449fe0)+0xf4 /sys/src/cmd/acme/buff.c:118
> > > > > q=0x3400045a240
> > > > > blp=0x4089b0
> > > > > i=0x454d6000000340
> > > > > bl=0x454d60
> > > > > bufread(b=0x449fe0,q0=0x0,n=0x1,s=0x49598c)+0x47 /sys/src/cmd/acme/buff.c:288
> > > > > m=0x21ccf700000000
> > > > > textreadc(q=0x0)+0x46 /sys/src/cmd/acme/text.c:509
> > > > > r=0x20322500000000
> > > > > number(dir=0x0,line=0x8,t=0x449b38,.ret=0x495a38,size=0x100000001,r=0x0,evalp=0x495b54,md=0x4490c0)+0x25a /sys/src/cmd/acme/addr.c:98
> > > > > q0=0x20397900000000
> > > > > q1=0x1
> > > > > address(.ret=0x495af0,ar=0x0,q0=0x0,q1=0x1,a=0x45a250,getc=0x220bdb,qp=0x495b5c,t=0x449b38,md=0x4490c0,lim=0xffffffffffffffff,evalp=0x495b54)+0x58d /sys/src/cmd/acme/addr.c:247
> > > > > r=0x0
> > > > > q=0x800000001
> > > > > dir=0x224d1100000000
> > > > > size=0x1
> > > > > prevc=0x100000000
> > > > > nr=0x495a5c
> > > > > c=0x38
> > > > > n=0x4089b000000008
> > > > > npat=0x100000001
> > > > > pat=0x0
> > > > > xfidwrite(x=0x493ad0)+0x5d1 /sys/src/cmd/acme/xfid.c:459
> > > > > w=0x4499e0
> > > > > qid=0xa
> > > > > fc=0x4810b0
> > > > > t=0x449b38
> > > > > nr=0x100000001
> > > > > r=0x45a250
> > > > > eval=0x100000001
> > > > > a=0x1
> > > > > nb=0xa00000001
> > > > > err=0x497c00
> > > > > q0=0x449b3800000000
> > > > > tq0=0x23396a
> > > > > tq1=0x23396a00000000
> > > > > buf=0x41e8e000000000
> > > > > xfidctl(arg=0x493ad0)+0x35 /sys/src/cmd/acme/xfid.c:52
> > > > > x=0x493ad0
> > > > > launcheramd64(arg=0x493ad0,f=0x22373a)+0x10 /sys/src/libthread/amd64.c:11
> > > > > 0xfefefefefefefefe ?file?:0
> > > > >
> > > >
> > >
> >
>
next prev parent reply other threads:[~2023-10-09 21:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-09 19:42 unobe
2023-10-09 20:07 ` ori
2023-10-09 20:11 ` unobe
2023-10-09 20:19 ` ori
2023-10-09 20:36 ` unobe
2023-10-09 21:50 ` ori [this message]
2023-10-09 23:41 ` unobe
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=001381913807BCD917D0F119B18A8060@eigenstate.org \
--to=ori@eigenstate.org \
--cc=9front@9front.org \
/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).