ctors defined twice in .h and .C files

[wenmang]

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.

 

[wenmang]

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

 

[Ron Natalie]

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.

 

[wenmang]

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.


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

 

[Zara]

On 29 Jun 2006 07:22:13 -0700, "(e-mail address removed)" <[email protected]>
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

 

[Zara]

On 29 Jun 2006 07:22:13 -0700, "(e-mail address removed)" <[email protected]>
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

 

[wenmang]

On 29 Jun 2006 07:22:13 -0700, "(e-mail address removed)" <[email protected]>
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