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