Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

C++ Programming

Need help on rogue wave template classes..


I am  using evaluation copy of RW 9.0 for porting one of C++
application on RHEL4 (x86 platform).
We are getting some issues into RW template classes. Please need
assistance on this issue.

Here is the problem:

Application is using below mentioned template class which is declared
at static in Engine.h

RWTPtrHashDictionary<RWCString, RuleClass RWDefHArgs(RWCString)>
  Engine::ruleHash(RWCString::hash);

Above line definition is found in Engine.C at the beginning of the
file.

Here is sample piece of code where ruleHash is used. This code is
Engine.C. I am calling insertRule(this) static method from RuleClass.h
file.

Void Engine::insertRule( RuleClass* newRule )
{
   RuleClass* rule = NULL;
   if( 0 != ruleHash.entries() )
    ............
   Core dump....

}

Application is using template object  ruleHash to call entries()
method.
I am getting core dump at releHash.entries() line. Its not only with
entries method, it crashes for any methods of RWTPtrHashDictionary.
I have also tried with other template class RWTValDlist<RWCString> to
test whether it is problem with deprecated RWTPtrHashDictionary
template.
But I see that application crashes for RWTValDlist template too.

FYI: gdb output

(gdb) p ruleHash
$1 = {<RW_PMapAssoc<rw_hashmap<RWCString*, RuleClass*,
rw_deref_hash<RWTHasher<RWCString>, RWCString>,
rw_deref_compare<std::equal_to<RWCString>, RWCString>,
std::allocator<RWCString*> >,RWTPtrHashMap<RWCString, RuleClass,
RWTHasher<RWCString>, std::equal_to<RWCString>,
std::allocator<RWCString*> >,RWCString,RuleClass,std::less<RWCString>

>> = {<RW_PMapCntnr<rw_hashmap<RWCString*, RuleClass*,

rw_deref_hash<RWTHasher<RWCString>, RWCString>,
rw_deref_compare<std::equal_to<RWCString>, RWCString>,
std::allocator<RWCString*> >,RWTPtrHashMap<RWCString, RuleClass,
RWTHasher<RWCString>, std::equal_to<RWCString>,
std::allocator<RWCString*> >,RWCString,RuleClass>> =
{<RW_PBase<rw_hashmap<RWCString*, RuleClass*,
rw_deref_hash<RWTHasher<RWCString>, RWCString>,
rw_deref_compare<std::equal_to<RWCString>, RWCString>,
std::allocator<RWCString*> >,RWTPtrHashMap<RWCString, RuleClass,
RWTHasher<RWCString>, std::equal_to<RWCString>,
std::allocator<RWCString*> > >> = {<No data fields>}, <No data
fields>}, <No data fields>}, impl_ = {impl = {
      listAllocator =
{<__gnu_cxx::new_allocator<rw_internal_pair_slist<std::pair<RWCString*
const, RuleClass*>, long unsigned int,
std::allocator<std::pair<std::pair<RWCString* const, RuleClass*>, long
unsigned int> > > >> = {<No data fields>}, <No data fields>},
      vectorAllocator =
{<__gnu_cxx::new_allocator<std::vector<LHashTable<std::pair<RWCString*
const, RuleClass*>, rw_hashmap<RWCString*, RuleClass*,
rw_deref_hash<RWTHasher<RWCString>, RWCString>,
rw_deref_compare<std::equal_to<RWCString>, RWCString>,
std::allocator<RWCString*> >::h_k, rw_hashmap<RWCString*, RuleClass*,
rw_deref_hash<RWTHasher<RWCString>, RWCString>,
rw_deref_compare<std::equal_to<RWCString>, RWCString>,
std::allocator<RWCString*> >::eq_k, std::allocator<RWCString*>
>::bucket_t, std::allocator<LHashTable<std::pair<RWCString* const,

RuleClass*>, rw_hashmap<RWCString*, RuleClass*,
rw_deref_hash<RWTHasher<RWCString>, RWCString>,
rw_deref_compare<std::equal_to<RWCString>, RWCString>,
std::allocator<RWCString*> >::h_k, rw_hashmap<RWCString*, RuleClass*,
rw_deref_hash<RWTHasher<RWCString>, RWCString>,
rw_deref_compare<std::equal_to<RWCString>, RWCString>,
std::allocator<RWCString*> >::eq_k, std::allocator<RWCString*>
>::bucket_t> > >> = {<No data fields>}, <No data fields>}, list_ =

0x0, table_ = 0x0, eq_ = {eq_ =
{<std::binary_function<RWCString*,RWCString*,RWBoolean>> = {<No data
fields>},
          cmp_ = {<std::binary_function<RWCString,RWCString,bool>> =
{<No data fields>}, <No data fields>}}}, hash_ = {
        h_ = {<std::unary_function<RWCString*,unsigned int>> = {<No
data fields>}, hash_ = {hfun_ = 0}}}}}}
(gdb) bt
#0  0x08068308 in rw_slist<std::pair<std::pair<RWCString* const,
RuleClass*>, unsigned long>,
std::allocator<std::pair<std::pair<RWCString* const, RuleClass*>,
unsigned long> > >::size (this=0x0)
    at /opt/RogueWave/SourcePro/Ed9_Eval/rw/stdex/slist.h:322
#1  0x08066c1f in LHashTable<std::pair<RWCString* const, RuleClass*>,
rw_hashmap<RWCString*, RuleClass*, rw_deref_hash<RWTHasher<RWCString>,
RWCString>, rw_deref_compare<std::equal_to<RWCString>, RWCString>,
std::allocator<RWCString*> >::h_k, rw_hashmap<RWCString*, RuleClass*,
rw_deref_hash<RWTHasher<RWCString>, RWCString>,
rw_deref_compare<std::equal_to<RWCString>, RWCString>,
std::allocator<RWCString*> >::eq_k, std::allocator<RWCString*> >::size
(this=0x8436f50)
    at /opt/RogueWave/SourcePro/Ed9_Eval/rw/stdex/lhash.h:586
#2  0x08064620 in rw_hashmap<RWCString*, RuleClass*,
rw_deref_hash<RWTHasher<RWCString>, RWCString>,
rw_deref_compare<std::equal_to<RWCString>, RWCString>,
std::allocator<RWCString*> >::size (this=0x8436f50)
    at /opt/RogueWave/SourcePro/Ed9_Eval/rw/stdex/hashmap.h:256
#3  0x0806280b in RW_PBase<rw_hashmap<RWCString*, RuleClass*,
rw_deref_hash<RWTHasher<RWCString>, RWCString>,
rw_deref_compare<std::equal_to<RWCString>, RWCString>,
std::allocator<RWCString*> >, RWTPtrHashMap<RWCString, RuleClass,
RWTHasher<RWCString>, std::equal_to<RWCString>,
std::allocator<RWCString*> > >::entries (this=0x8436f50)
    at /opt/RogueWave/SourcePro/Ed9_Eval/rw/ep_cntnr.h:82
#4  0x08060c8d in RuleEngine::insertRule (newRule=0x84373f8) at
RuleEngine.C:179
#5  0x0806fe20 in RuleClass (this=0x84373f8, ruleName=@0xbff2a2e0) at /
common/Rule/inc/RuleClass.h:30
#6  0x08080dac in ServiceLevelRule (this=0x84373f8) at /common/Rule/
inc/ServiceLevelRule.h:37
#7  0x08080887 in __static_initialization_and_destruction_0
(__initialize_p=1, __priority=65535)
    at /common/Rule/src/ServiceLevelRule.C:15
#8  0x08080cd9 in global constructors keyed to
_ZN16ServiceLevelRule7executeER7Package ()
    at /common/Rule/src/ServiceLevelRule.C:179
#9  0x0837c9a1 in __do_global_ctors_aux ()
#10 0x0805139d in _init ()
#11 0x0837c90a in __libc_csu_init ()
#12 0x03517d91 in __libc_start_main () from /lib/tls/libc.so.6
#13 0x080526e1 in _start ()
(gdb)

Please need help on this. Is it problem with initilizing the static
variables?. I am waiting for you reply.

Thanks & Regards,
Prakash

prakash.mi@gmail.com a crit :[snip]

It seems you have a static initialization order problem.

Use singleton pattern if you can or avoid using static initialisation of
  object using another static object (ruleHash in this case).

Alternatively, you can swap the order of the object at final link to
ensure ruleHash is initialized first (not portable but that doesn't seem
to be an issue in your case).

Otherwise, have a look at your compiler's doc. They may have custom
procedures for this kind of problem.

Michael

Hi Prakash,

On May 28, 8:18 am, prakash.mi@gmail.com wrote:

> I am  using evaluation copy of RW 9.0 for porting one of C++
> application on RHEL4 (x86 platform).

The best place to ask questions about our SourcePro libraries,
especially the evaluation copies, is the Rogue Wave forum.
Alternatively, you can try our tech support -- they'll be more than
happy to assist you.

> We are getting some issues into RW template classes. Please need
> assistance on this issue.

> Here is the problem:

> Application is using below mentioned template class which is declared
> at static in Engine.h

> RWTPtrHashDictionary<RWCString, RuleClass RWDefHArgs(RWCString)>
>   Engine::ruleHash(RWCString::hash);

> ......

I believe the issue you are observing is not specific to the SourcePro
classes; judging by the appearance of the stack trace you are posting,
it seems it has to do with the structure of your program and it seems
it is an issue related to the order of initialization of objects with
static storage duration which are dependent on each other. FWIW, this
is a relatively frequent issue in the reports and requests for help we
are receiving from customers. You must employ an appropriate technique
to make sure your globals are initialized when you first use them.

This is the page with the relevant information on how to get support
from us:
http://www.roguewave.com/support/contact/index.cfm#sourcepro

HTH,
Liviu

nikkoara a crit :

> On May 28, 8:18 am, prakash.mi@gmail.com wrote:
>> I am  using evaluation copy of RW 9.0 for porting one of C++
>> application on RHEL4 (x86 platform).
> [snip]

> This is the page with the relevant information on how to get support
> from us:
> http://www.roguewave.com/support/contact/index.cfm#sourcepro

I am not a native english speaker but the following extracted from the
roguewave web site striked me:

SourcePro Core: An extensive set of fundamental C++ components that
shields users from many of the intricacies of the C++ language.[snip]

I see that "shielding user from the intricacies of the C++ language" is
an asset.
Marketing reality or I am missing the point ? :)

Michael

On May 28, 3:31 pm, Michael DOUBEZ <michael.dou@free.fr> wrote:

Yes, that seems to be "marketing speak". I agree it does not sound
right. Thanks for pointing it out, I'll pass this to the people in
marketing.

Liviu

On May 28, 3:31 pm, Michael DOUBEZ <michael.dou@free.fr> wrote:

Yes, that seems to be "marketing speak". I agree it does not sound
right. Thanks for pointing it out, I'll pass this to the people in
marketing.

Liviu

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc