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

ctors defined twice in .h and .C files

P: n/a
Here is the code which causes core dump when is built differently, 1
for regular dev built, the other for packaging build.

class my_class{
public:
my_class(){};
~my_class(){};

private:
string myData1;
string myData2;

};

x.C file:
my_class::my_class() : myData1(), myData2()
{
}
my_class::~my_class()
{
}

Obviously, ctor/dtor are defined twice in .h and .C files. Here is my
question:
1. are myData1 and myData2 are initialized or not when ctor/dtor
defined in .h are called?
2. What behaviour of compiler if ctor/dtor are defined twice?
3. debug trace indicates that one of two strings are not initialized,
here is debug output:
debug> p myData1
{
_String_base::_M_start=NULL
_String_base::_M_finish=NULL
_String_base::_M_end_of_storage=NULL
static basic_string::npos=4294967295
}
Can I safely say that myData1 memory is not allocated at this point, if
string assignment happens, it will lead core-dump, right?

Thx.

Jun 27 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a
My bad, made a mistake, here is my correct question to be asked:

I have a class, and string members are initilized through their own
ctors:
class my_class{
public:
my_class();
~my_class();
private:
string myData1;
string myData2;
};

my_class::my_class() myData1(), myData2()
{
}

Now, the problem occurs for two diff builts. I traced the problem which
inside SGI STL string implementation:
inline char* uninitialized_copy(const char* __first, const char*
__last,
char* __result) {
memmove(__result, __first, __last - __first);
return __result + (__last - __first);
}
__result is "_M_finish" which is a part of class _String_alloc_base{}
class. __result(_M_finish) is not allocated enough space before memmove
is called which causes core-dump. But, the other build binary does
allocate enough space. Both built are using the same make file and
built on same UnixWare platform. I am guessing that allocator for
string may not be called correctly for some reason and memory
allocation is not happening correctly for this case. Do we have a way
to force allocator being called or is there other explanation on this?
How could this happen?
thx

Jun 28 '06 #2

P: n/a
we*****@yahoo.com wrote:
My bad, made a mistake, here is my correct question to be asked:

I have a class, and string members are initilized through their own
ctors:
class my_class{
public:
my_class();
~my_class();
private:
string myData1;
string myData2;
};

my_class::my_class() myData1(), myData2()
This is ill-formed syntax (you need a :) and totally redundant.
The two strings will be default initiallized (it's only POD's
that the stupid-assed language doesn't bother to properly
default initialize without being told) without it.
Do we have a way
to force allocator being called or is there other explanation on this?
How could this happen?


Most likely you are screwing up something somewhere else and it's
just showing up here.

Common errors are passing (char*) NULL to one of the string member
functions or otherwise writing off some piece of dyanamic storage.

Post a complete, minimal program that demosntrates the problem.
Jun 29 '06 #3

P: n/a

Ron Natalie wrote:
we*****@yahoo.com wrote:
My bad, made a mistake, here is my correct question to be asked:

I have a class, and string members are initilized through their own
ctors:
class my_class{
public:
my_class();
~my_class();
private:
string myData1;
string myData2;
};

my_class::my_class() myData1(), myData2()


This is ill-formed syntax (you need a :) and totally redundant.
The two strings will be default initiallized (it's only POD's
that the stupid-assed language doesn't bother to properly
default initialize without being told) without it.
Do we have a way
to force allocator being called or is there other explanation on this?
How could this happen?


Most likely you are screwing up something somewhere else and it's
just showing up here.

Common errors are passing (char*) NULL to one of the string member
functions or otherwise writing off some piece of dyanamic storage.

Post a complete, minimal program that demosntrates the problem.


Here is similar class we used and it generates core-dump for one of two
builts.
class my_class{
public:
my_class();
~my_class();
void setData1(const string input) { myData1 = input; }
:
:
private:
string myData1;
string myData2;
};
my_class::my_class() : myData1(), myData2()
{
}

When member function setData1() is called, it sometimes core-dump(in
one built) at memmove. Here is the stack trace(all names are replaced
with dummy ones):

Stack Trace for p1.1, Program mytest
*[0] memmove(0x1, 0x10ac2551, 0x3) [0xbffa0d66]
[1] basic_string<T1, T2, T3>::append<U1>(U1, U1, forward_iterator_tag)
[with T1=char, T2=char_traits<char>, T3=allocator<char>, U1=const char
*, return type=basic_string<char, char_traits<char>, allocator<char>>
&](this=0xed0b308, __first="5354", __last="",
={}) [mytest.C@stl_uninitialized.h@85]
[2] basic_string<T1, T2, T3>::_M_append_dispatch<U1>(U1, U1,
__false_type) [with T1=char, T2=char_traits<char>, T3=allocator<char>,
U1=const char *, return type=basic_string<char, char_traits<char>,
allocator<char>> &](this=0xed0b308, __f="5354", __l="",
={}) [mytest.C@string@607]
[3] basic_string<T1, T2, T3>::append<U1>(U1, U1) [with T1=char,
T2=char_traits<char>, T3=allocator<char>, U1=const char *, return
type=basic_string<char, char_traits<char>, allocator<char>>
&](this=0xed0b308, __first="5354", __last="") [mytest.C@string@564]
[4] basic_string<T1, T2, T3>::assign(const T1 *, const T1 *) [with
T1=char, T2=char_traits<char>, T3=allocator<char>, return
type=basic_string<T1, T2, T3> &](this=0xed0b308, __f="5354",
__l="") [mytest.C@string@1302]
[5] my_class::setData1 (basic_string<char, char_traits<char>,
allocator<char>>)(this=0xed0ae68, input={"5354", "",
"e"}) [mytest.C@string@360]
I did some tests e.g., by adding myData1.reverse(10) in ctor, still it
core-dumps. You see that the arg passed to setData1() has meaningful
value, I don't think that there is the bug in code, but may have
something to do with compiler(maybe?). I need advice howto approach
this. Thx

Jun 29 '06 #4

P: n/a
On 29 Jun 2006 07:22:13 -0700, "we*****@yahoo.com" <we*****@yahoo.com>
wrote:
<...>


Here is similar class we used and it generates core-dump for one of two
builts.
class my_class{
public:
my_class();
~my_class();
void setData1(const string input) { myData1 = input; }
:
:
private:
string myData1;
string myData2;
};
my_class::my_class() : myData1(), myData2()
{
}

When member function setData1() is called, it sometimes core-dump(in
one built) at memmove. Here is the stack trace(all names are replaced
with dummy ones):

Stack Trace for p1.1, Program mytest
*[0] memmove(0x1, 0x10ac2551, 0x3) [0xbffa0d66]

<...>

Obviously, the destination of memmove is wrong. The only explanations
that comes to my mind are:

a) you are trying to execute the function setData1 on something that
is not a my_class instance. If your are referring to the instance
through a pointer, it migh be an unintialized or null pointer

b) you have some kind of memory corruption elsewhere that corrupts the
contents of the instance of my_class, or the reference or pointer it.

FWITW, I think a) is more likely, with a null pointer as memmove is
trying to access memory location "0x1", that is, one more than 0x0
that typically is the internal representation of a null pointer.

Best regards,

Zara
Jun 30 '06 #5

P: n/a
On 29 Jun 2006 07:22:13 -0700, "we*****@yahoo.com" <we*****@yahoo.com>
wrote:
<...>


Here is similar class we used and it generates core-dump for one of two
builts.
class my_class{
public:
my_class();
~my_class();
void setData1(const string input) { myData1 = input; }
:
:
private:
string myData1;
string myData2;
};
my_class::my_class() : myData1(), myData2()
{
}

When member function setData1() is called, it sometimes core-dump(in
one built) at memmove. Here is the stack trace(all names are replaced
with dummy ones):

Stack Trace for p1.1, Program mytest
*[0] memmove(0x1, 0x10ac2551, 0x3) [0xbffa0d66]

<...>

Obviously, the destination of memmove is wrong. The only explanations
that comes to my mind are:

a) you are trying to execute the function setData1 on something that
is not a my_class instance. If your are referring to the instance
through a pointer, it migh be an unintialized or null pointer

b) you have some kind of memory corruption elsewhere that corrupts the
contents of the instance of my_class, or the reference or pointer it.

FWITW, I think a) is more likely, with a null pointer as memmove is
trying to access memory location "0x1", that is, one more than 0x0
that typically is the internal representation of a null pointer.

Best regards,

Zara
Jun 30 '06 #6

P: n/a

Zara wrote:
On 29 Jun 2006 07:22:13 -0700, "we*****@yahoo.com" <we*****@yahoo.com>
wrote:
<...>


Here is similar class we used and it generates core-dump for one of two
builts.
class my_class{
public:
my_class();
~my_class();
void setData1(const string input) { myData1 = input; }
:
:
private:
string myData1;
string myData2;
};
my_class::my_class() : myData1(), myData2()
{
}

When member function setData1() is called, it sometimes core-dump(in
one built) at memmove. Here is the stack trace(all names are replaced
with dummy ones):

Stack Trace for p1.1, Program mytest
*[0] memmove(0x1, 0x10ac2551, 0x3) [0xbffa0d66]

<...>

Obviously, the destination of memmove is wrong. The only explanations
that comes to my mind are:

a) you are trying to execute the function setData1 on something that
is not a my_class instance. If your are referring to the instance
through a pointer, it migh be an unintialized or null pointer

b) you have some kind of memory corruption elsewhere that corrupts the
contents of the instance of my_class, or the reference or pointer it.

FWITW, I think a) is more likely, with a null pointer as memmove is
trying to access memory location "0x1", that is, one more than 0x0
that typically is the internal representation of a null pointer.

Best regards,

Zara


Here is some more info:
1196: uninitialized_copy(__f1, __last, _M_finish + 1);
inside uninitialized_copy:
85: memmove(__result, __first, __last - __first);
debug> p _result
""
debug> p &_result
0x7fffc158

The stack trace for memmove is not exactly the case(copy to 0x1), it
core-dumps at line 85, print content and address of __result, yields
above. At this point, I am not sure whether __result is pointing to
already allocated memory or not. For the other built, the result is
different:
85: memmove(__result, __first, __last - __first);
debug> p _result
"\326\245\020\004\201\243\020\264\347\247\020y\001 "
debug> p &_result
0x7fffc158

Any idea what happened to __result? thx

Jun 30 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.