On Thu, 6 Oct 2005, CLEMENT Francis wrote: > Is it a coincidence or not but now glst 'next gen' blocks again !!! > 1 process get 100% cpu then any other glst processes wait = > indefinitively ... > and xmail logs error -5 in windows application logs and its filters log = > for > the offending process and then others glst waiting : > SMTP filter error (-5): Filter =3D "c:\xmailtools\glst\glst.exe" > > When killing the offending glst process (using 100%) then the others = > glst > processes end by themself (no need to kill them manually) and all goes = > ok... > > XMail Smtp and filters logs don't show intensive smtp in connections (I > suspected a 'spam attack' ...) > > To be sure its not a faulty gdmb database, I deleted the current and = > let > glst create it from scratch.
I think I give up on this. With another user, we've been able to identify where the infinite loop is, and it is a condition that should never happen if the database is not corrupted. The GDBM bug list (and google) does not show any sign of such reports, and GDBM is pretty heavily used in the Unix world. No, the database size is not a problem, since I use it in other projects with DB up to several hundreds MB. OTOH the Win32 "port" is really nothing, since the GDBM code uses almost completely POSIX functions. There must be something in the code generation (MS VC++?) that trigger the condition, or the GLST processes gets brutally killed while updating the DB files. - Davide - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
