* [9front] acme: suicide when using upas/Mail
@ 2023-10-09 19:42 unobe
2023-10-09 20:07 ` ori
0 siblings, 1 reply; 7+ messages in thread
From: unobe @ 2023-10-09 19:42 UTC (permalink / raw)
To: 9front
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [9front] acme: suicide when using upas/Mail
2023-10-09 19:42 [9front] acme: suicide when using upas/Mail unobe
@ 2023-10-09 20:07 ` ori
2023-10-09 20:11 ` unobe
0 siblings, 1 reply; 7+ messages in thread
From: ori @ 2023-10-09 20:07 UTC (permalink / raw)
To: 9front
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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [9front] acme: suicide when using upas/Mail
2023-10-09 20:07 ` ori
@ 2023-10-09 20:11 ` unobe
2023-10-09 20:19 ` ori
0 siblings, 1 reply; 7+ messages in thread
From: unobe @ 2023-10-09 20:11 UTC (permalink / raw)
To: 9front
read error from temp file
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
> >
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [9front] acme: suicide when using upas/Mail
2023-10-09 20:11 ` unobe
@ 2023-10-09 20:19 ` ori
2023-10-09 20:36 ` unobe
0 siblings, 1 reply; 7+ messages in thread
From: ori @ 2023-10-09 20:19 UTC (permalink / raw)
To: 9front
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
> > >
> >
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [9front] acme: suicide when using upas/Mail
2023-10-09 20:19 ` ori
@ 2023-10-09 20:36 ` unobe
2023-10-09 21:50 ` ori
0 siblings, 1 reply; 7+ messages in thread
From: unobe @ 2023-10-09 20:36 UTC (permalink / raw)
To: 9front
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.
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
> > > >
> > >
> >
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [9front] acme: suicide when using upas/Mail
2023-10-09 20:36 ` unobe
@ 2023-10-09 21:50 ` ori
2023-10-09 23:41 ` unobe
0 siblings, 1 reply; 7+ messages in thread
From: ori @ 2023-10-09 21:50 UTC (permalink / raw)
To: 9front
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
> > > > >
> > > >
> > >
> >
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [9front] acme: suicide when using upas/Mail
2023-10-09 21:50 ` ori
@ 2023-10-09 23:41 ` unobe
0 siblings, 0 replies; 7+ messages in thread
From: unobe @ 2023-10-09 23:41 UTC (permalink / raw)
To: 9front
Quoth ori@eigenstate.org:
> 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.
Ah snap! I forgot about that. Thanks for the additional insight.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-10-09 23:46 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-09 19:42 [9front] acme: suicide when using upas/Mail 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
2023-10-09 23:41 ` unobe
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).