Sure! I don't entirely understand the scope of the problem, though. Is this something that we can do elegantly in the current code, or do we just need to hack it a little bit in a few places? For a more thorough solution, what about an exception framework, with wrappers around fgets and fprintf that raise exceptions if something goes wrong. Take a look at this:
http://ldeniau.home.cern.ch/ldeniau/html/exception/exception.html I have already emailed the author to find out what his licensing terms are; nothing is mentioned on that page or in the code. Aaron Paul J Stevens <[EMAIL PROTECTED]> said: > Ive been doing some more testing and debugging on this problem. I think > the problem is in imap4.c > > Client issues a close. > Server continues reading and writing on closed streams. > Client responds with RST packets. > Server barfs on EPIPE. > > There is no check in the code before each read/write on whether the > stream is still open. I would guess that all read/write actions on the > streams should check their state. > > Perhaps the fgets and fprintf call should be moved to wrapper calls that > do proper error handling. Any takers ? > > > Paul J Stevens wrote: > > I've done some more testing. It's real simple to trigger this bug: > > simply telnet on port 143 and quit without doing anything. > > > > Even though the client sends a FIN,ACK to the server, the server still > > responds with * BAD No tag specified. It should respond by closing the > > streams instead. > > > > Doesn't solve the problems with mozilla though :-( > > > > Aaron Stone wrote: > > > >> What's an active close? > >> > >> Going off on a tangent, I started reading over severchild.c to see what I > >> could see, and I noticed this big FIXME towards the end of > >> PerformChildTask() > >> > >> db_disconnect(); > >> auth_disconnect(); > >> connected = 0; /* FIXME a signal between this line and the > >> previous one > >> * would screw things up. Would like to have all > >> this in > >> * db_disconnect() making 'connected' obsolete > >> */ > >> > >> To prevent the signal problem, create a noop function and set it as the > >> universal signal handler right before the disconnection code. Any signals > >> coming in during the "critical shutdown zone" would basically be ignored. > >> > >> Right, and now back to our regularly scheduled bug hunt ;-) > >> > >> Aaron > >> > >> > >> Paul J Stevens <[EMAIL PROTECTED]> said: > >> > >> > >>> As promised: I've zoomed in on a tcp session that goes haywire. > >>> > >>> I've attached such a session in a pcap file: see attachment. > >>> > >>> Looks like mozilla initiates an active close after receiving a 'OK > >>> STATUS completed' but dbmail failes to properly close the session, > >>> leading to the client sending RST packets that trigger the broken > >>> pipe problem. > >>> > >>> I guess serverchild.c needs some serious refactoring... :-) > >>> > >>> > >>> Paul J Stevens wrote: > >>> > >>>> I don't really think its the acl stuff that's causing this. 1.2.3 > >>>> has similar problems with mozilla type clients, it just got much > >>>> worse on 2.x. > >>>> > >>>> I'll investigate and see what I can come up with. > >>>> > >>>> > >>>> Aaron Stone wrote: > >>>> > >>>> > >>>>> I see this with Mozilla 1.6, too. In fact, it was driving me nuts > >>>>> when I was > >>>>> testing my latest patch because I thought I had ruined the delivery > >>>>> chain... > >>>>> only to try KMail instead and discover that things really were > >>>>> working ;-) > >>>>> > >>>>> Someone should sit down with a tcpdump or ethereal-type protocol > >>>>> analyzer and > >>>>> try getting to the bottom of this! KMail does not support the > >>>>> Namespace > >>>>> extension, and might not support ACL either. So something about one > >>>>> or both > >>>>> must be a little bit buggered, either by us or Mozilla; only a true > >>>>> patch will > >>>>> tell :-) > >>>>> > >>>>> Aaron > >>>>> > >>>>> > >>>>> ""Blake Mitchell"" <[EMAIL PROTECTED]> said: > >>>>> > >>>>> > >>>>> > >>>>>> This sounds very similar to the problems I am having with > >>>>>> Mozilla/Thunderbird and 2.0rc2. Only access to the INBOX, doesn't > >>>>>> check for > >>>>>> mail when I tell it to, etc. So far my only solution has been to > >>>>>> use Outlook > >>>>>> :-/ > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: [EMAIL PROTECTED] > >>>>>> [mailto:[EMAIL PROTECTED] On > >>>>>> Behalf Of Paul J Stevens > >>>>>> Sent: Tuesday, February 24, 2004 8:18 AM > >>>>>> To: dbmail-dev@dbmail.org > >>>>>> Subject: Re: [Dbmail-dev] unable to read mail on 2.x > >>>>>> > >>>>>> I'm guessing it's a client related issue. > >>>>>> > >>>>>> This occurs when I access dbmail-2 from a thunderbird-0.5 client > >>>>>> that has several accounts with many folders configured. > >>>>>> > >>>>>> I've also moved my dbmail-2 imap server around to a UML instance > >>>>>> on the same machine as my dbmail-1 server, and also to a totally > >>>>>> different machine in the same network. > >>>>>> > >>>>>> In all cases: thunderbird triggers the closed pipe error, whereas > >>>>>> squirrelmail and ilohamail work just fine. > >>>>>> > >>>>>> I've finally tested this with mozilla-1.6 with only one account: > >>>>>> same problem. One additional thing I noticed though: on first > >>>>>> accessing a new account, mozilla and thunderbird hang while > >>>>>> 'Getting folder ACL'. > >>>>>> > >>>>>> Closing and restarting the client gives me access to the INBOX, > >>>>>> but no other folders. weird... > >>>>>> > >>>>>> I've tested with balsa and with sylpheed. Oops. Same broken-pipe. > >>>>>> No problems reading email though. > >>>>>> > >>>>>> ... > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Dbmail-dev mailing list > >>>>>> Dbmail-dev@dbmail.org > >>>>>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>> -- > >>> ________________________________________________________________ > >>> Paul Stevens [EMAIL PROTECTED] > >>> NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 > >>> The Netherlands_______________________________________www.nfg.nl > >>> _______________________________________________ > >>> Dbmail-dev mailing list > >>> Dbmail-dev@dbmail.org > >>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >>> > >> > >> > >> > >> > > > > -- > ________________________________________________________________ > Paul Stevens [EMAIL PROTECTED] > NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 > The Netherlands_______________________________________www.nfg.nl > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > --
