On Tue Apr 7 21:50:14 EDT 2009, r...@swtch.com wrote: > > abort()+0x0 /sys/src/libc/9sys/abort.c:6 > > plumbpackattr(attr=0x28b00)+0x126 /sys/src/libplumb/mesg.c:125 > > n=0x93 > > a=0x3e990 > > s=0x3a430 > > t=0x3a497 > > t is unlikely to be correct here; it would have been saved > at the last call to strlen but since then got +='ed with the result. > > > acid: regs() > > PC 0x0000c80c abort /sys/src/libc/9sys/abort.c:6 > > SP 0x00068e78 ECODE 0x00000004 EFLAG 0x00000206 > > CS 0x00000023 DS 0x0000001b SS 0x0000001b > > GS 0x0000001b FS 0x0000001b ES 0x0000001b > > TRAP 0x0000000e page fault > > AX 0x0003a4c3 BX 0x0003a4c6 CX 0x0003a430 DX 0x00000093 > > DI 0x0003a4c7 SI 0x0003ea19 BP 0x0003e9f0 > > there's s+n in AX. t is likely to be BX or DI, judging from the > pointer values; it has either written 3 or 4 bytes past the > end of the allocated section, which explains the abort. > you'd have to disassemble plumbpackattr to make sure. > it would be interesting to print *(*plumbpackattr:s\s) > to see if the string is corrupted.
acid: *(*plumbpackattr:s\s) filetype=mail sender=x...@xxxx.xxx length=8749 mailtype=delete date='Sun Mar4de7153cecd4a9b45aead1clfs digest=aff98fb56526d94ab768adbc93d12d989a11ed53 hmmm. i think you might be on to something after all. maybe it was fratricide. > i don't understand what you mean. > plumbers clients are always waiting for something > to happen. the plumber's only job is to tell them > when it does. several were waiting on something else to happen; they were sleeping waiting for an exclusive-open file. the only reason i mentioned it is that may have been 5 minutes between the time that plumber tried to write the message and when it could be delivered. > i suspect the global buffer in plumbpackattr's quote. > if you had multiple threads running through > plumbpackattr at once, it might cause the kind of crash you saw. > all the ordinary plumbing is protected by the QLock named queue, > but it looks like maybe if you'd been writing the rules file > at exactly the same time, that might have triggered > a simultaneous plumbpackattr call. unfortunately, i was not writing the rules file, that i know of. - erik
