Quoth Nicola Girardi via 9fans <[email protected]>:
> The process stuck writing to the seemail port is indeed upas/fs:
> 
>         312 fs Pwrite 21a04c 5  
> 0x44c160/"mailfs.seemail./mail/[email protected]" 
> 205 -1
> 
> This makes sense, because the process that needs to receive the
> message is Mail, which is itself stuck, here are the last few lines
> from its trace:
> 
>         403 Mail Open 21ac1c 0x40e000/"/mail/fs/ctl" 0x1 = 16 "" 173579477431 
> 173584571672
>         [... omitted two successful writes to other fids ...]
>         403 Mail Pwrite 20ace8 16  0x472c78/"delete.mbox.9" 13 -1
> 
> which suggests that Mail is waiting for upas/fs to receive the message
> written to the control file, so they're deadlocked; I'll test this hypothesis.
> 
> For comparison, here's what the trace would look like when Mail does
> not get stuck:
> 
>         415 Mail Pwrite 20ace8 16  0x472c78/"delete.mbox.6" 13 -1 = 13 "" 
> 163054398681 163274619092
>         415 Mail Close 21ac3a 16 = 0 "" 163275175643 163275183465
> 
> > The most useful thing you could do would be to capture
> > stacks from all of the Mail procs that are hanging,
> > and send them; see lstk(1) or acid.
> 
> Okay, thanks the pointers Ori.  I'll send this reply while I have a
> working Mail+upas/fs pair!  and will check stack traces later.

AFAICS the stack traces support that theory.  Mbmain() processes both
seemail messages (from upas/fs) and events (from acme).  Maybe those
could be different procs?

acid: lstk() # Mail
pwrite(a0=0x10)+0xe /sys/src/libc/9syscall/pwrite.s:6
write(buf=0x472c78,n=0x200000000d)+0x27 /sys/src/libc/9sys/write.c:7
_fmtFdFlush(f=0x472d78)+0x3a /sys/src/libc/fmt/vfprint.c:15
vfprint(args=0x472e20,fmt=0x405d7a)+0x6f /sys/src/libc/fmt/vfprint.c:31
fprint(fmt=0x405d7a)+0x22 /sys/src/libc/fmt/fprint.c:13
mbflush()+0x15a /sys/src/cmd/upas/Mail/mbox.c:733
doevent(ev=0x40d460)+0x11f /sys/src/cmd/upas/Mail/mbox.c:990
mbmain(cmd=0x40ee60)+0x1fc /sys/src/cmd/upas/Mail/mbox.c:1039
launcheramd64(arg=0x40ee60,f=0x20270b)+0x10 /sys/src/libthread/amd64.c:11
0xfefefefefefefefe ?file?:0

And he's upas/fs sending to the seemail port in the proc that
processes the commands:

acid: lstk() # upas/fs
pwrite(a0=0x5)+0xe /sys/src/libc/9syscall/pwrite.s:6
write(buf=0x44a7a0,n=0x7fff000000c4)+0x27 /sys/src/libc/9sys/write.c:7
myplumbsend(fd=0x5,m=0x7fffffffc7b0)+0x47 /sys/src/cmd/upas/fs/mbox.c:1573
mailplumb(m=0x455370,mb=0x4387f0)+0x3d4 /sys/src/cmd/upas/fs/mbox.c:1650
syncmbox(mb=0x4387f0,doplumb=0x1)+0x177 /sys/src/cmd/upas/fs/mbox.c:105
delmessages(ac=0x2,av=0x7fffffffcb90)+0x115 /sys/src/cmd/upas/fs/mbox.c:1107
rwrite(f=0x1ad)+0x285 /sys/src/cmd/upas/fs/fs.c:1238
io()+0x1e9 /sys/src/cmd/upas/fs/fs.c:1436
main(argc=0x0,argv=0x7fffffffef70)+0x31a /sys/src/cmd/upas/fs/fs.c:353
_callmain+0x38 /sys/src/libc/9sys/callmain.c:21

--
Nico - is unsure of next steps


------------------------------------------
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T92af154d081c9c25-M08f0f7d9fcb177efdfac4024
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Reply via email to