Hello everybody,
I have separated the following code from a large project. It crushes when I
click a form one or two times:
Simple thread with the following Execute method:
void __fastcall SGModule::Execute() {
short *fdata;
while(!Terminated) {
fdata = new short[10000];
delete[] fdata;
}
}
Event handler for TForm click:
void __fastcall TForm1::FormClick(TObject *Sender)
{
char *x;
for(unsigned i=0;i<1000;i++) {
x = new char[10];
delete[] x;
}
}
I am imcluding the only header file
#include <vcl.h>
I have tried to set IsMultiThread variable to true, which should solve the problem, but it haven't.
Does anybody know anything more about memory allocation in a multi threaded application in C++ Builder?
Any ideas welcome
Robert Batusek
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
Of course I am sure. I am really not a beginner and I have spent about 4 days by debugging (i. e. separating this code from thousands of lines of code). When I place new and delete statements into critical section, it stops to crash.
I can send you the whole code, if you are interested.
But maybe you are right with the run-time libraries. Where I have to set it up? I have tried to browse all option settings But I haven't been successfull.
Thanks.
Robert
Of course I am sure. I am really not a beginner and I have spent about 4 days by debugging (i. e. separating this code from thousands of lines of code). When I place new and delete statements into critical section, it stops to crash.
I can send you the whole code, if you are interested.
But maybe you are right with the run-time libraries. Where I have to set it up? I have tried to browse all option settings But I haven't been successfull.
Thanks.
Robert
I still didn't fix the problem.
I'll summarize it:
1. The code above crushes after some time.
2. When a synchronization technique is used to allocation/deallocation, it works OK.
IMHO it means that the memory manager is not thread-safe. And my question is:
How to make it thread safe? Is it possible?
How do I ensure I am using the right (multi-threaded) run-time libraries? If not, how can I switch to the right libraries?
And what about IsMultiThread global variable? Is it worth to change it?
Robert
>> IMHO it means that the memory manager
>> is not thread-safe
It appears that in Builder the memory manager is thread safe if the IsMultiThread global variable is set to true. Furthermore this is set to true automatically when a thread is started through the library procedures. So there should not be a problem. But you should check to make sure it is set to true. If it is set to false, that woudl be a problem.
Borland does not seem to have seperate single and multi-threaded libraries. VC does, and you woudl get this problem if you used the single-threaded library, but not with the multi-threaded library.
It is well known problem in BC 5.x, but it is suprice for me , that same problem exists in BCB.
Problem: after some times (~ 25,depends from apps) new /delete crashed in MultiThread project(if exist > 1 thread, of couse).
Solution 1: overload new/delete to you
own(use , for example, alloc/faralloc)
Solution 2: sincronisation (Critical section,Mutex,...)
In general: new/delete are NOT threadsaved in BC 5.x and now I see same in BCB.
By my info (before ~1 year): problem
exists in BC 5.02 too(but may be solved
in some patch).
Alex
I had the same problem in BC5, I spend days looking for it, (it never appeared on the same place) and even issued a bug report to borland (on which i never got a reply).
But it is true... borlands BC5 heap is not serialised and therefore not threadsafe.
The problem also was that the DLL's that BC5 programs use already had the heap linked to it, so overloading new and delete was no good, the dll's then use a different new then you're own code and it will crash. (Tried that... it crashed). This happens if you create a variable from the heap that is destroyed in the library or vice versa, something that will happen if you use Windows (OWL in BC5) objects. This is logically of cource, because only calls to new and delete that are linked are going to your overloaded new, the one's in the dll's don't (they were linked earlier, and know nothing of your overloaded new and delete).
Overloading new and delete globally can be considered bad practice!!
Finally I decided to STATICALLY link the app, and replace malloc and free in the library with winapi calls (LocalAlloc etc), to do that, you must localize the module in the library that contains the heap, there are two of them, (use TDump) write your own malloc and free and add them to the library. Unfortunatly there are some extra functions in those modules for heap checking (heap_walk etc), if you don't use them you can replace them with simple stubs (empty functions).
Things become simpler if you only use your own classes multithreaded.. in that case you can overload new and delete for that class.
Finally I must say that I was astonished when I found this bug... how could they ever be so stupid? And I'm even more astonished that they didn't fix it in BCB. Alex: I tried every patch in BC5 ... no result, and as I said, I issued a bug report, but never got a reply. Not that that is a suprise there was also a bug in BC5's auto_ptr implementation in STL, unfortunatly I never got a reply on that report too.
Luc
Now I have proved that the error is on the Borland side and I have to deal with it some how. LucHoltkamp, I will accept your answer, but I have one more question:
Ii is impossible to recompile RTL, because at least in my version of BCB, sources are not included. So, I propose this solution:
I have implemented my own new operator and in all my classes I am using it. I will try to implement also my own Allocator class, as I am using some objects from Standard C++ Library. I am quite sure, that I am not using any other objects or routines, or at least I don't use them in multi-threaded part of my application. Do you think, that this solution is satisfactory?
(In fact, I am testing it now, and it stil doesn't work, although it crushes much less frequently. But there still may be some unnoticed source code.)
And another note: I have reported the bug to Borland, hope that they will at least read it.
Thanks all for remarks
Robert
One problem is that in your code, I see you create a char with new, you cannot overload the operator new for char's, and a globally operator new will not work... so your solution only works if you use ONLY your own classes that have a overloaded operator new.
For my solution, you do not need the source code, you just replace the heap module in the library, all the function declaration are known, they are in the headers, so it is possible to rewrite them.
Business Accounts
Answer for Membership
by: nietodPosted on 2000-09-01 at 03:51:36ID: 4154767
You must use the multi-threaded libraries (specified in the compiler settings) and then new and delete will be multi-thread safe. Are you?
Are you sure this is where it is crashing? there must be other code too.