| Summary: | Multiple ORBs cannot be destroyed out of order they were created | ||
|---|---|---|---|
| Product: | TAO | Reporter: | Ossama Othman <ossama.othman> |
| Component: | ORB | Assignee: | Ossama Othman <ossama.othman> |
| Status: | RESOLVED --- | ||
| Severity: | minor | ||
| Priority: | P3 | ||
| Version: | 1.1 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Attachments: | Simple sample code that demonstrates the problem. | ||
|
Description
Ossama Othman
2000-06-08 16:14:20 CDT
Accepted. Created attachment 42 [details]
Simple sample code that demonstrates the problem.
Doug pointed out that the problem wasn't with TAO, but with the application
code.
--------8<--------8<--------8<--------8<--------8<--------8<--------
Doug wrote:
Did you run Purify or BoundsChecker on your program? If so,
you will see why it's seg faulting. It has nothing to do with TAO --
it has to do with the way that your program is designed. Check out
the following:
>> inline int ORBWorker::svc (void) {
>> mOrb->run();
>> return 0;
>> }
This thread is running, yet you then turn around and delete the memory
"out from underneath it" here:
>> delete ms1;
>> delete ms2;
My guess is that the following code isn't getting the ORB to return
from the loop and fully shutdown the thread-specific resources in the
MasterServer task before you delete mWorker:
>> MasterServer::~MasterServer() {
>> mPOA->destroy (true, true);
>> mRootPOA->destroy (true, true);
>> mORB->shutdown (false);
>> mORB->destroy();
>> delete mWorker;
>> }
Thus, there's a race condition that'll cause seg-faults.
I suggest that you restructure your program to handle this stuff a
different way (which I leave as an "exercise" for you since I don't
know what you're trying to accomplish t a higher-level here!).
|