Re: [Bug: 21.5-b13] zenicb looses sync

Sorry, no reproducable test case yet, but a little more info. I traced an xemacs process until it misbehaved and got this: 327 xemacs-21.5-b13 GIO fd 7 read 75 bytes "Jbxxxxxx\^Aif you apply ktrace, which file is it processing when it cr\ ashes?\0" 327 xemacs-21.5-b13 RET read 75/0x4b This is perfectly valid ICB input, correct len code (J = 75 byte) and zero terminated buffer. 327 xemacs-21.5-b13 CALL read(0x7,0x87d7600,0x200) 327 xemacs-21.5-b13 RET read -1 errno 35 Resource temporarily unavailable 327 xemacs-21.5-b13 CALL read(0x7,0x87d7600,0x200) 327 xemacs-21.5-b13 RET read -1 errno 35 Resource temporarily unavailable 327 xemacs-21.5-b13 CALL read(0x7,0x87d7600,0x200) 327 xemacs-21.5-b13 RET read -1 errno 35 Resource temporarily unavailable 327 xemacs-21.5-b13 CALL __sigaction_sigtramp(0xd,0x82083b0,0x82083c8,0x4846d934,0x1) 327 xemacs-21.5-b13 RET __sigaction_sigtramp 0 This is SIGPIPE being delivered - and the first time this happens in the whole zenicb session. 327 xemacs-21.5-b13 CALL __sigaction_sigtramp(0xd,0x82083b0,0x82083c8,0x4846d934,0x1) 327 xemacs-21.5-b13 RET __sigaction_sigtramp 0 327 xemacs-21.5-b13 CALL __sigaction_sigtramp(0xd,0x82083b0,0x82083c8,0x4846d934,0x1) 327 xemacs-21.5-b13 RET __sigaction_sigtramp 0 327 xemacs-21.5-b13 CALL write(0x8,0x82a1ac0,0x29) 327 xemacs-21.5-b13 GIO fd 8 wrote 41 bytes "(hwhereis\^Atrace, which file is it proces\0" 327 xemacs-21.5-b13 RET write 41/0x29 And here a "whereis" request is sent with parts of the above read buffer mistaken as a nick name (which would happen legitimately if the above input would have been a privat message from "trace, ...."). So it appears somewhere in the SIGPIPE handler something is stomping over the input buffer and mangling it. Don't ask me why SIGPIPE happens here. Martin