PureBasic Forums - English

I have to trap errors in program.
For that reason I enabled OnError lines support
Additionally I have enabled ThreadSafe Executable,
Unicode support as program is Unicode,
Admin mode as program uses privileged operations.
EnabledExplicite and DisableDebugger.

Program runs on server with proper MACAddress, IP, HOSTNAME and Filename and accessing FTP, MSSQL, PGSQL and SQLITE.
That is the reason why I cannot test it and debug.

Program crashes without notifying/reporting and when the program crashes handles(FTP or SQL) left open and many trash files are left on disk.

Because of OnErrorCall bug Threads are not detecting ShutDownFlag which is global or shared.
OnErrorCall procedure should set ShutDownFlag True and Threads should terminate normally.

How this can be solved.

Have a look at this topic. It allows you to send messages to the system debug api, and also includes a link to the Sysinternals DebugView app which will allow you to collect the messages.
http://www.purebasic.fr/english/viewtop ... 12&t=14231

You might find Luis' assert macro useful...
http://www.purebasic.fr/english/viewtop ... lit=assert

And Didelphodon's event log include too...
http://www.purebasic.fr/english/viewtop ... lit=syslog

Perfect Spikey with debugger, what about catching error?
Because OnErrorCall declared once and very usefull but if works.
TryCatch have to be used everytime if you suspect the code block may crash.

OnErrorCall us usefull to clean trashes, freeup memory and terminate program correctly.

Is there a way to use OnErrorCall or OnErrorGoto so it really catches failures???

I've never observed a problem with OnErrorCall - but that doesn't mean that a bug is impossible, however I think its more likely that there is a specific problem with your program which is the root cause.

You haven't posted faulty code so any advice can't be more than general, and from what you describe its probably not feasible to post faulty code at this point anyway so you're going to have to try some hunting on your own...

I suggest you put a system debug call right at the top of the the OnErrorCall procedure:-
OutputDebugString("Entered OnErrorProcedureName")

a second after you set the ShutDownFlag = True to make sure this actually happened:-
OutputDebugString("ShutDownFlag" + StrU(ShutDownFlag))

and a third right at the end
OutputDebugString("Exited OnErrorProcedureName")

This will tell you in the DebugView message queue if the procedure is actually being called and terminating properly.

I'd also put debug messages in the threads and procedures in the same way to see if they start up and shut down as expected, and also that their return values make sense and that they react to the ShutDownFlag change. Hopefully you'll notice something isn't occurring exactly the way you expect and then you can target your inspections closer to home in on the problem.

Where particular things must be in order for other things to work correctly ASSERT that this is the case - and if not output some content which will help you work out what went wrong.

Bear in mind that threads will take time to end - they may not terminate immediately just because you've told them to.

One of the biggest headaches in threaded and networked programs is something called multi user interference - where process A changes something that B wasn't expecting right now or to a value B wasn't expecting at all and this causes a problem further down the line in C which was dependent upon B having its house in order.

OnErrorCall won't necessarily fire in this circumstance anyway because the problem isn't a purely error driven failure its an "error in context" fault caused by flawed logic...

You need to think about what could go wrong and flag up the possibilities - then run and see what's actually happening at runtime.

Thank You very much for correct solutions.
Going to check that to be sure OnError is active or not.