It doesnt dr watson for everyone. For most people it either just stops or keeps running but doesnt respond.
Line numbers: standard delphi just raises an access violation at address. I cant compile mike's versions exactly to find an address as I dont have access to delphi 5. I've been working with Alan Fiebig trying 3rd part exception handlers that will tell me the line numbers in the stack trace (without much success). We've tried eurekalog which didnt get anywhere. I'm looking at another one now to see if it's any different. Threads: The winshoes (smtprcv uses v7, indy 9 is current and 10 is about to be released) IP library for delphi does all the threading work. I've been through all mike's and my code to make sure that anything we've written that could clash is protected with a critical section. If I could duplicate the crash, it would be a lot easier as I can run the program under delphi and it will break at the exception and let me look at where it is and what all the variables were. (Anyone game enough to install delphi on their machine and run smtprcv under it? I'm compiling with delphi 7 personal which was free off a magazine cover so we can do it without buying it). I noticed that everyone who sent a config back was nt4 sp6a. Has anyone got a w2k/xp/w2k3 that's crashing? Am I looking for some sort of incompatability with the nt4 ip stack and the code I'm running? Next year I might look at a big rewrite to delphi 7 service application with indy 10. klint. On Tue, 16 Dec 2003 21:38:21 -0600, "Gordon Fecyk - Home" <[EMAIL PROTECTED]> wrote: > I'm guessing that SMTPRCV EXE is dumping to a drwstn32.log and is providing > some kind of information in there somewhere. > > When I write code for LCC these days, I compile with the built-in debug and > line number support turned on during testing. With that it tells me where > in my code, which function and which line the crash occurred. The > debugger's compiled right into the binary, so a non-LCC user can see this > information. Don't modern versions of Delphi include this kind of debugging > support? > > At least with that, the folks who are getting crashes could at least tell > Klint where in the code it's crashing and why. It will also help if the > code in question wasn't running as a Service (smtprcv -debug as pointed out > earlier), or if running as a Service have "Interact with Desktop" turned on > so a debug window will at least display itself. > > >From observing the comments I've read so far, it looks like a problem with > two or more threads colliding on a bit of shared data, and there isn't a > working locking mechanism (mutex / semaphore) used to prevent that. A > multi-processor system seems to have more trouble, probably because there's > more of a chance of thread collision on that. > > What kind of thread functions come with a current Delphi environment? Is > there a special version of CreateThread() provided? Are there provisions to > use locking (mutex/semaphore/criticalsection/etc) built in or are you > required to use the Win32 functions such as WaitForSingleObject() yourself? > Also beware that some of these things are NT4 or Win2K specific, such as > TryEnterCriticalSection() which is NT4 specific. > > I couldn't read Delphi source to save my soul, but if this were C code I'd > look for every bit of data that could conceivably be shared between threads > and make sure there's a lock of some kind on them, depending on the nature > of what's being shared. This especially includes log file handles. > Alternately, try to make as much stuff not shared as practical, by making > some global variables local variables instead. Or do both. If stuff can be > read by multiple threads safely but only written once, this is tricky in > Win32 (it was easier on the Amiga because it was possible to have multiple > read locks on something but only one write lock - on Win32 you'd need both a > semaphore and a mutex to accomplish the same thing). +---------------------------------------+-----------------+ : Klint Gore : "Non rhyming : : EMail : [EMAIL PROTECTED] : slang - the : : Snail : A.B.R.I. : possibilities : : Mail University of New England : are useless" : : Armidale NSW 2351 Australia : L.J.J. : : Fax : +61 2 6772 5376 : : +---------------------------------------+-----------------+ This is the discussion list for the IMS Free email server software. To unsubscribe send mailto:[EMAIL PROTECTED] Delivered by Rockliffe MailSite http://www.rockliffe.com/mailsite Rock Solid Software (tm)
