Hi
I don't know if this helps but with thread problems we have noticed they
show/ appear more on hyperthreaded CPUs (and I assume multi core CPUs).
A few years ago we had a situation where a clients pc crashed but ours
was fine. We thought it was a problem with the clients machine but it
turns out it was a problem with our thread code. If your are not
testing on a HT or multi core CPU try that, you might be able to
replicate it for yourself (and therefore fix it easier).
Rob Martin
Software Engineer
phone +64 03 377 0495
fax +64 03 377 0496
web www.chreos.com
Wild Software Ltd
Gajo Csaba wrote:
Hello,
I wrote a multithreaded application for a client and it crashes on the
client's computer, while it works ok on mine. Can someone give me a
clue as to what might be the problem?
The program works like this: I have two TThreadLists: one contains a
list of keywords (~20000) while the other a list of proxy servers
(~500). When the user clicks on the button, 21 threads are created. 1
thread directly accesses Google, enters the keyword and processes the
result. The other 20 threads do the same, except they use a proxy server.
OK, so each thread grabs a keyword from the list and then removes it
from the list, so no one else could use it again. It tries to access
the internet. If the connection fails then it means the proxy doesn't
work, so it gets another proxy address from the list. No two threads
ever share the same proxy. If there are no more free proxies left, the
thread dies (and returns the unprocessed keyword to the list).
They do this until all the keywords are processed. When it seems like
there are no more keywords left, the 1st thread (the one not using a
proxy) changes its priority to tpLowest and loops forever, waiting for
another keyword to show up.
Like I said, this works perfectly on my computer. On the client's
computer (Windows XP I think) an error dialog pops up saying:
<program name> has encountered a problem and needs to close. We are
sorry for the inconvenience.
If you were in the middle of something, the information you were
working on might be lost.
If the client clicks on the Close button, the entire application will
shut down. However, if he ignores the message, the application will
keep on working and it will eventually finish it's job, and then the
client can export the result to a file.
Because the application works fine, I'm guessing this is just one
thread that has crashed. The problem is the error dialog shouldn't
appear. I didn't make it appear with MessageDlg, so it must be
Windows' internal something. The error occurs somewhere at the start,
around the 1000th keyword.
I tried lowering the number of threads to 5, but this didn't help either.
Any idea what may be causing this problem? The only two shared global
variables are the lists, though they are in the main unit, not in the
same unit where the threads are. But these are TThreadLists so they
should be thread-safe. There are no other global variables.
The thread's Execute method itself does not contain a try-except
block. I guess I could try this and then when an exception occurs I do
not display an error message - but I'm not sure if this would solve
the problem.
To download a file from the Internet I use a modified version of the
GetInetFile method found at
http://delphi.about.com/od/internetintranet/l/aa013001a.htm However
this method is also sorrounded with a try-except block which should
prevent this kind of error.
I don't know if there's anything else. Anyone has an idea what went
wrong? Why it works perfectly on my computer and doesn't on the clients?
I'm using Delphi 5, no custom components. I'm also using Windows XP
with service pack 2.
If you've read the whole mail then thank you :)
If you could also suggest what the error might be then I would be most
grateful. I've looked through the entire code several times and can't
see anything that's wrong in it. Everything seems to be synchronized,
when I access the items of the ThreadList I use LockList-UnlockList...
The only thing that isn't synchronized is the GetInetFile method, but
I'm guessing that shouldn't be a problem. Or should it?
Thanks,
Csaba
_______________________________________________
Delphi mailing list
[email protected]
http://ns3.123.co.nz/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list
[email protected]
http://ns3.123.co.nz/mailman/listinfo/delphi
