By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,857 Members | 1,793 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,857 IT Pros & Developers. It's quick & easy.

Need help on rogue wave template classes..

P: n/a
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<RWCStringto
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*,RWBoo lean>= {<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

May 28 '07 #1
Share this Question
Share on Google+
5 Replies


P: n/a
pr***********@gmail.com a écrit :[snip]
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....

}
[snip]
#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.
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
May 28 '07 #2

P: n/a
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/con....cfm#sourcepro

HTH,
Liviu

May 28 '07 #3

P: n/a
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/con....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

May 28 '07 #4

P: n/a
On May 28, 3:31 pm, Michael DOUBEZ <michael.dou...@free.frwrote:
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/con....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 ? :)
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

May 28 '07 #5

P: n/a
On May 28, 3:31 pm, Michael DOUBEZ <michael.dou...@free.frwrote:
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/con....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 ? :)
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

May 28 '07 #6

This discussion thread is closed

Replies have been disabled for this discussion.