Hi,
we're having a 'situation' with a multithreaded Delphi 6 app that just disappears without so much as a hint of what went wrong. No traces even in the OS (XP) event log. In our lab we decided to try madExcept (latest v) to see if it would catch this problem. It does not.
Are there known situations where madExcept fails to catch exceptions? In a multithreaded app, are there special precautions required to ensure we get stack trace and exception information from madExcept?
BTW all threads are TThread descendants, and implement a catch-all try-except handler in proc Execute.
TIA, Kristofer
Silent crash in multithreaded app - madExcept not helping?
Hi kristofer,
read your post in the borland newsgroups, too...
I think there are a number of possible reasons for a disapprearing app:
(1) Someone close the app behind your back.
(2) Stack overflows sometimes make big problems.
(3) Follow up exceptions in try..except blocks can make problems.
(4) If the memory manager breaks (or fragments too much), the whole program will run into problems, since you can't do much without memory allocation. (Even Delphi strings need a working memory manager, as you most probably know).
(5) If someone is writing trash into random memory locations, this can destroy important data or also important code sections. This again can result in one of the above mentioned problems.
What can you do? You can try to do something against each of the mentioned problems:
(1) Add a MessageBox after Application.Run indicating that you're closing friendly. Plus: Run the "HookProcessTermination" demo contained in the madCodeHook Demos folder. This demo will catch all TerminateProcess calls and show them to you.
(2) That's a difficult one. Can you increase stack size in Delphi? Not sure... The stack size defaults are contained in the "OptionalHeader" of your exe file. I guess those values are used for the main thread. The secondary threads are internally created by TThread. You could probably edit Classes.pas to give the TThreads more stack.
(3) In all your try..except blocks begin with creating an empty file on C:\ with "CloseHandle(CreateFile('c:\crash', ...))". By using simple string constants this doesn't need any allocation. So the danger of follow up exceptions is less than otherwise.
(4) Try one of the replacement memory managers. If they fix the problem, then you know that Delphi's default MM was the guilty one.
(5) Ouch. Nothing you can do here, I guess.
read your post in the borland newsgroups, too...
I think there are a number of possible reasons for a disapprearing app:
(1) Someone close the app behind your back.
(2) Stack overflows sometimes make big problems.
(3) Follow up exceptions in try..except blocks can make problems.
(4) If the memory manager breaks (or fragments too much), the whole program will run into problems, since you can't do much without memory allocation. (Even Delphi strings need a working memory manager, as you most probably know).
(5) If someone is writing trash into random memory locations, this can destroy important data or also important code sections. This again can result in one of the above mentioned problems.
What can you do? You can try to do something against each of the mentioned problems:
(1) Add a MessageBox after Application.Run indicating that you're closing friendly. Plus: Run the "HookProcessTermination" demo contained in the madCodeHook Demos folder. This demo will catch all TerminateProcess calls and show them to you.
(2) That's a difficult one. Can you increase stack size in Delphi? Not sure... The stack size defaults are contained in the "OptionalHeader" of your exe file. I guess those values are used for the main thread. The secondary threads are internally created by TThread. You could probably edit Classes.pas to give the TThreads more stack.
(3) In all your try..except blocks begin with creating an empty file on C:\ with "CloseHandle(CreateFile('c:\crash', ...))". By using simple string constants this doesn't need any allocation. So the danger of follow up exceptions is less than otherwise.
(4) Try one of the replacement memory managers. If they fix the problem, then you know that Delphi's default MM was the guilty one.
(5) Ouch. Nothing you can do here, I guess.
Silent crash in multithreaded app - madExcept not helping?
Thanks,
that's valuable advice from someone who makes crash trapping software for a living. We'll be sure to look closely at these points.
Kristofer
that's valuable advice from someone who makes crash trapping software for a living. We'll be sure to look closely at these points.
Kristofer
-
EricLenington
- Posts: 2
- Joined: Sun Nov 06, 2005 12:48 am
Same problem...
Kristofer,
Have you made any progress on this issue? I am having the exact same problem.
A note: I believe that all threads use the stack allocation as set in the Delphi linker options--my application has over 500 threads, and will actually run out of memory on startup if the minimum stack size is too large.
An idea: Using madExcept, is there a good place to put a CreateBugReport that would trap the current state of all threads right before the application exits? Not in response to an exception, just using madExcept.CreateBugReport to dump the application state? Maybe right after Application.Run in the Project Source (or there, inside a try/finally)?
Regards,
Eric
Any thoughts Madshi?
Have you made any progress on this issue? I am having the exact same problem.
A note: I believe that all threads use the stack allocation as set in the Delphi linker options--my application has over 500 threads, and will actually run out of memory on startup if the minimum stack size is too large.
An idea: Using madExcept, is there a good place to put a CreateBugReport that would trap the current state of all threads right before the application exits? Not in response to an exception, just using madExcept.CreateBugReport to dump the application state? Maybe right after Application.Run in the Project Source (or there, inside a try/finally)?
Regards,
Eric
Any thoughts Madshi?
Re: Same problem...
There are many different causes why an application can exit. If it's because of trouble, then madExcept will probably not work properly anymore, anyway...EricLenington wrote:An idea: Using madExcept, is there a good place to put a CreateBugReport that would trap the current state of all threads right before the application exits? Not in response to an exception, just using madExcept.CreateBugReport to dump the application state? Maybe right after Application.Run in the Project Source (or there, inside a try/finally)?
