- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - Linux
- >
- Run time issues with STL string class
Operating System - Linux
1748186
Members
4438
Online
108759
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-31-2007 01:52 AM
08-31-2007 01:52 AM
Run time issues with STL string class
Hi,
I'm facing some problem while executing C++ binary.
The below is the environment under which our code is being compiled and being run:
OS :
- Red Hat Enterprise Linux ES release 4 (Nahant Update 4)
Thread model:
- posix
gcc version :
3.4.3 20041212 (Red Hat 3.4.3-9.EL4)
glibc :
glibc-2.3.4-2.25
glibc-devel-2.3.4-2.25
glibc-kernheaders-2.4-9.1.98.EL
glibc-2.3.4-2.25
glibc-devel-2.3.4-2.25
compat-glibc-2.3.2-95.30
glibc-utils-2.3.4-2.25
glibc-common-2.3.4-2.25
compat-glibc-headers-2.3.2-95.30
glibc-headers-2.3.4-2.25
glibc-profile-2.3.4-2.25
compat-glibc-2.3.2-95.30
and the below is the code snippet. (it is not actual code, just a kind of example like our code ).
Code Snippet:
class A
{
public:
A() : namePresent(false) {};
virtual void setName(const string& name)
{
this -> name = name;
namePresent = true;
}
virtual const string& getName()
{
return name;
}
private:
string name;
bool namePresent;
};
class B : public A
{
public:
B() : A(){
.... // some other initialisation.
}
};
class C : public B
{
public:
C(const string &name1) : B()
{
------
-------
initialise(name1);
------
-------
}
int initialise(const string &name1)
{
------
-------
setName(name1)
--------
}
void setName(const string& name2)
{
A :: setName(name2);
..... // some code
.....
}
}
main()
{
C* temp = new C("XYZ");
}
This is an example to show the hierarchy of the class inheritence that is there in our code.
We have been able to create an pointer object of the class C and also been able to call the setName function of the class A for the first object.
But for the second time(rather second pointer object) it is giving the core dump. The below is the gdb of the core:
#0 0xffffe405 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe405 in __kernel_vsyscall ()
#1 0x005007a5 in raise () from /lib/tls/libc.so.6
#2 0x00502209 in abort () from /lib/tls/libc.so.6
#3 0x0053471a in __libc_message () from /lib/tls/libc.so.6
#4 0x0053afbf in _int_free () from /lib/tls/libc.so.6
#5 0x0053b33a in free () from /lib/tls/libc.so.6
#6 0x0099ffd1 in operator delete () from /usr/lib/libstdc++.so.6
#7 0x00981cff in std::string::_Rep::_M_destroy () from /usr/lib/libstdc++.so.6
#8 0x00981e11 in std::string::assign () from /usr/lib/libstdc++.so.6
#9 0x00981e61 in std::string::operator= () from /usr/lib/libstdc++.so.6
#10 0x08158337 in mt::Task::setName (this=0x8234eb0, name=@0xffff9f90) at Task.cpp:38
#11 0x081600da in timer::TimerManager::setNameNew (this=0x8234eb0, p_name2=@0xffff9f90) at Timers.cpp:471
#12 0x0815fe58 in timer::TimerManager::initialise (this=0x8234eb0, name1=@0xffff9f90) at Timers.cpp:431
#13 0x0815edd3 in TimerManager (this=0x8234eb0, p_timerThreadsCount=1, p_name1=@0xffff9f90, p_useSignals=true,
p_timeoutProcessorFactory=0x0) at Timers.cpp:326
#14 0x0805c4a6 in VoiceFilter::initialiseInterface (this=0x8201420) at VoiceFilter.ecpp:653
#15 0x08070fe6 in VoiceFilterBase::initialise (this=0x8201420) at VoiceFilterBase.ecpp:302
#16 0x0806498f in main (argc=2, argv=0x8201420) at main.ecpp:62
If we set the environment variable MALLOC_CHECK_ to 1 then we donâ t see any such issue and binary works fine.
Interestingly we randomly see this behavior.
Any help very much appreciated.
( The same is attached here in a file as well)
Regards,
Sumanth
I'm facing some problem while executing C++ binary.
The below is the environment under which our code is being compiled and being run:
OS :
- Red Hat Enterprise Linux ES release 4 (Nahant Update 4)
Thread model:
- posix
gcc version :
3.4.3 20041212 (Red Hat 3.4.3-9.EL4)
glibc :
glibc-2.3.4-2.25
glibc-devel-2.3.4-2.25
glibc-kernheaders-2.4-9.1.98.EL
glibc-2.3.4-2.25
glibc-devel-2.3.4-2.25
compat-glibc-2.3.2-95.30
glibc-utils-2.3.4-2.25
glibc-common-2.3.4-2.25
compat-glibc-headers-2.3.2-95.30
glibc-headers-2.3.4-2.25
glibc-profile-2.3.4-2.25
compat-glibc-2.3.2-95.30
and the below is the code snippet. (it is not actual code, just a kind of example like our code ).
Code Snippet:
class A
{
public:
A() : namePresent(false) {};
virtual void setName(const string& name)
{
this -> name = name;
namePresent = true;
}
virtual const string& getName()
{
return name;
}
private:
string name;
bool namePresent;
};
class B : public A
{
public:
B() : A(){
.... // some other initialisation.
}
};
class C : public B
{
public:
C(const string &name1) : B()
{
------
-------
initialise(name1);
------
-------
}
int initialise(const string &name1)
{
------
-------
setName(name1)
--------
}
void setName(const string& name2)
{
A :: setName(name2);
..... // some code
.....
}
}
main()
{
C* temp = new C("XYZ");
}
This is an example to show the hierarchy of the class inheritence that is there in our code.
We have been able to create an pointer object of the class C and also been able to call the setName function of the class A for the first object.
But for the second time(rather second pointer object) it is giving the core dump. The below is the gdb of the core:
#0 0xffffe405 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe405 in __kernel_vsyscall ()
#1 0x005007a5 in raise () from /lib/tls/libc.so.6
#2 0x00502209 in abort () from /lib/tls/libc.so.6
#3 0x0053471a in __libc_message () from /lib/tls/libc.so.6
#4 0x0053afbf in _int_free () from /lib/tls/libc.so.6
#5 0x0053b33a in free () from /lib/tls/libc.so.6
#6 0x0099ffd1 in operator delete () from /usr/lib/libstdc++.so.6
#7 0x00981cff in std::string::_Rep::_M_destroy () from /usr/lib/libstdc++.so.6
#8 0x00981e11 in std::string::assign () from /usr/lib/libstdc++.so.6
#9 0x00981e61 in std::string::operator= () from /usr/lib/libstdc++.so.6
#10 0x08158337 in mt::Task::setName (this=0x8234eb0, name=@0xffff9f90) at Task.cpp:38
#11 0x081600da in timer::TimerManager::setNameNew (this=0x8234eb0, p_name2=@0xffff9f90) at Timers.cpp:471
#12 0x0815fe58 in timer::TimerManager::initialise (this=0x8234eb0, name1=@0xffff9f90) at Timers.cpp:431
#13 0x0815edd3 in TimerManager (this=0x8234eb0, p_timerThreadsCount=1, p_name1=@0xffff9f90, p_useSignals=true,
p_timeoutProcessorFactory=0x0) at Timers.cpp:326
#14 0x0805c4a6 in VoiceFilter::initialiseInterface (this=0x8201420) at VoiceFilter.ecpp:653
#15 0x08070fe6 in VoiceFilterBase::initialise (this=0x8201420) at VoiceFilterBase.ecpp:302
#16 0x0806498f in main (argc=2, argv=0x8201420) at main.ecpp:62
If we set the environment variable MALLOC_CHECK_ to 1 then we donâ t see any such issue and binary works fine.
Interestingly we randomly see this behavior.
Any help very much appreciated.
( The same is attached here in a file as well)
Regards,
Sumanth
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP