| Summary: | core dump in __static_initialization_and_destruction_0 | ||
|---|---|---|---|
| Product: | TAO | Reporter: | Oliver M. Kellogg <oliver.kellogg> |
| Component: | ORB | Assignee: | DOC Center Support List (internal) <tao-support> |
| Status: | REOPENED --- | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 1.2.8 | ||
| Hardware: | All | ||
| OS: | All | ||
|
Description
Oliver M. Kellogg
2003-01-02 18:09:39 CST
From: Balachandran Natarajan <bala@cse.wustl.edu> Message-ID: <15892.28251.182043.118823@macarena.cs.wustl.edu> Date: Thu, 2 Jan 2003 10:52:43 -0600 To: Oliver.Kellogg@t-online.de (Oliver Kellogg) Cc: tao-bugs@cs.wustl.edu, bala@cse.wustl.edu Subject: Re: [tao-bugs] Re: TAO 1.2.7: core dump in __static_initialization_and_destruction_0 [...] On Thursday, 2 January, 2003 at 09:56:48 +0100, Oliver Kellogg wrote: [snipped] > The question is: What is the exact point in time that the > TAO_Changer changes the service_config repo? When you initialize the ORB. The ORB, during the part of initialization configures the resource factory that needs to be used. > We could be accessing the repo either before or after it has been > altered by the TAO_Changer, but due to static initialization issues, > we have no way of knowing. Since we have a static object, the implicit assumption is that the objects are constructed before it reaches main (). But there is a subtle problem with the ordering though, which hasnt bit us, yet (touch wood :-)) > If the accesses shall be made on the altered repo then all such > accesses must themselves call the_instance(). The ORB doesnt really know whether the repo needs to be altered or not. If the user wants to configure the ORB with the stuff in the strategies library, then he would have linked in the library and included the advanced_resources.h file. This would pull in the symbols to construct the object and add stuff to the service_config repository. Am I missing something here? Accept for tao-support Accepted for tao-support Not sure how this got closed. This is *still* a problem. From: Carlos O'Ryan (spam_magnet@dev.null) Subject: Re: [tao-bugs] Re: TAO 1.2.7: core dump in __static_initialization_and_destruction_0 Newsgroups: comp.soft-sys.ace Date: 2003-01-02 09:50:07 PST Hi, Oliver.Kellogg@t-online.de (Oliver Kellogg) writes: > Instead, we need an explicit call for the TAO_Changer to do its > thing. Without more context your statement triggers an automatic response of mine: do *NOT* make the life of people that have decent compiler/linker combos harder because somebody has a bad toolset/OS. If there is a reason to disable the automatic initialization in advance_resource.h the procedure should be like this: 1) For platforms where the automatic initialization work, leave it as it is. 2) Disable the automatic initialization for platforms where it does not work. 3) Provide an explicit initializer for platforms that need it. 4) Make the explicit initializer a no-op for platforms that do not need it. --- end of quote from posting by Carlos --- I would argue that the problem is a conceptual one. How do you expect a linker to find out about the dependencies? It would have to analyze the executable statements in the code to infer the dependencies - a totally non-trivial and non-intuitive task IMHO. (For example, what about possible recursions.) So, contrary to what the Summary title and some of the previous discussion may suggest, I am NOT reporting this as a problem on a specific tool environment, but as a general problem. Oliver I just found further evidence - within the very TAO source tree itself. Near the beginning of the main program in $TAO_ROOT/orbsvcs/examples/RtEC/MCast/MCast.cpp, there is a comment: // Register the default factory in the Service Configurator. // If your platform supports static constructors then you can // simply using the ACE_STATIC_SVC_DEFINE() macro, unfortunately TAO // must run on platforms where static constructors do not work well, // so we have to explicitly invoke this function. TAO_EC_Default_Factory::init_svcs (); I would venture that users that haven't run into the problem are at least sensitized when they read this comment. So again, my vote is to not rely on implicit ordering of static initialization at all - in particular because the problem is aggravated when using ldopen(). Oliver |