[Ace-users] [tao-bugs] Crash in TAO_ORB_Core_Static_Resources::instance()
J.T. Conklin
jtc at acorntoolworks.com
Wed Oct 31 18:33:42 CDT 2007
TAO VERSION: 1.6.1 (2007-10-29 svn snapshot)
ACE VERSION: 5.6.1
HOST MACHINE and OPERATING SYSTEM:
NetBSD orac.acorntoolworks.com 3.0_STABLE NetBSD 3.0_STABLE (ORAC) #0: Tue Feb 21 20:05:51 PST 2006 jtc at orac.acorntoolworks.com:/home/jtc/netbsd/NetBSD-3/src/sys/arch/i386/compile/ORAC i386
TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
NetBSD orac.acorntoolworks.com 3.0_STABLE NetBSD 3.0_STABLE (ORAC) #0: Tue Feb 21 20:05:51 PST 2006 jtc at orac.acorntoolworks.com:/home/jtc/netbsd/NetBSD-3/src/sys/arch/i386/compile/ORAC i386
COMPILER NAME AND VERSION (AND PATCHLEVEL):
gcc version 3.3.3 (NetBSD nb3 20040520)
THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform-
specific file, simply state which one]:
config-netbsd.h
THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE [if you
use a link to a platform-specific file, simply state which one
(unless this isn't used in this case, e.g., with Microsoft Visual
C++)]:
platform_netbsd.GNU
CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
(used by MPC when you generate your own makefiles):
N/A
AREA/CLASS/EXAMPLE AFFECTED:
TAO_ORB_Core_Static_Resources::instance()
DOES THE PROBLEM AFFECT:
EXECUTION
SYNOPSIS:
Core dump in TAO_ORB_Core_Static_Resources::instance()
DESCRIPTION:
While the TAO unit tests look pretty good on my platform, many of my
own applications dump core in a static constructor when initializing
TAO_ORB_Core_Static_Resources::initialization_reference_ via the
TAO_ORB_Core_Static_Resources::instance() factory method.
TAO_ORB_Core_Static_Resources*
TAO_ORB_Core_Static_Resources::instance (void)
{
ACE_Service_Gestalt *current = ACE_Service_Config::current();
TAO_ORB_Core_Static_Resources* tocsr =
ACE_Dynamic_Service<TAO_ORB_Core_Static_Resources>::instance
(current,"TAO_ORB_Core_Static_Resources",true);
if (tocsr == 0)
{
// This new is never freed on purpose. The data specified by
// it needs to be around for the last shared library that references
// this class. This could occur in a destructor in a shared library
// that is unloaded after this one. One solution to avoid this
// harmless memory leak would be to use reference counting.
current->process_directive(ace_svc_desc_TAO_ORB_Core_Static_Resources);
tocsr = ACE_Dynamic_Service<TAO_ORB_Core_Static_Resources>::instance
(current,"TAO_ORB_Core_Static_Resources",true);
ACE_Service_Gestalt *global = ACE_Service_Config::global();
if (current != global)
{
TAO_ORB_Core_Static_Resources* global_tocsr =
ACE_Dynamic_Service<TAO_ORB_Core_Static_Resources>::instance
(global,"TAO_ORB_Core_Static_Resources");
*tocsr = *global_tocsr;
}
}
// return TAO_ORB_Core_Static_Resources::instance_;
return tocsr;
}
The crash occurs in the "*tocsr = *global_tocsr" assignment. It appears
that instance() method has been called on a non-global gestalt before it
was called on the global one. So global_tocsr is null, and the assignment
fails when the fields are copied.
I'm not familiar with the new gestalt code, so I don't know whether an
invarient that requires that the global gestalt be initialized first
is being violated, or whether the ctor initialization order has
exposed a bug. I'm also not clear to me what the purpose of the local
tocsr being initialized from the global_tocsr. I forced to guess, I'd
say the intent is for the global one to be initialized first, possibly
modified, and ->process_directive() is called to create the gestalt, but
the intent is to overwrite it. But even that seems to assume ordering
of the initial creation of the global_toscr, it's initialization, and
the creation of "current" toscr's that doesn't seem manifest in the code.
But like I said, I'm not familiar with the gestalt code.
REPEAT BY:
No test case yet.
SAMPLE FIX/WORKAROUND:
--
J.T. Conklin
More information about the Ace-users
mailing list