DevOps, CI/CD and Automation

Hi,

We've recently upgraded to the sun studio 9 compiler and I'm noticing some rather odd behaviour while running through the debugger. This "odd behaviour" ultimately causes a coredump and I've managed to track it back to a place where it seems the constructors are getting quite a bit mixed up. I'm at a loss for why the compiled code is working in this way and not sure whether the compiler has chewed anything up. If anyone has any ideas, I would be most grateful.

This is a stripped down example, but you can get the point...

struct ds_def
{
ds_def() : last_sta_nam(" ") {}

fn_string<16> last_sta_nam; // this is a basic fixed-size string
// ... there are other data members in this struct also
};

struct intf_entry_def
{
intf_entry_def() { //.. does some minor initialisation }

ds_def ds_;
};

class X
{
public:
void foo()
{
intf_ptr_ = new intf_entry_def;
}
private:
intf_entry_def * intf_ptr_;
};

Using dbx, I stopped the running executable when in the ds_def::ds_def() constructor and had a look at some of the data members and their addresses....

(dbx) examine this
0x021a2588: 0x015db798

(dbx) print sizeof(*this)
sizeof(*this) = 784

(dbx) examine &last_sta_nam
0x021a2870: 0x00000000
(dbx) examine &this->last_sta_nam
0x021a2808: 0x015db798

(dbx) print -r last_sta_nam
last_sta_nam = {
last_sta_nam.data_ptr_ = (nil)
data_size_ = 0
data_set_ = false
pad_char_ = '\0'
data_ = ""
}
(dbx) print -r this->last_sta_nam
this->last_sta_nam = {
this->last_sta_nam.data_ptr_ = 0x21a2818 " "
data_size_ = 16U
data_set_ = true
pad_char_ = ' '
data_ = " "
}

Now, the odd thing here is that &last_sta_nam and &this->last_sta_nam are pointing to two separate areas in memory. As far as I'm aware, reference to "this" shouldnt make a difference but it does. This is why I'm wondering whether there is any compiler magic occuring, that is unfortunately getting it wrong. Printing using the "this" pointer yields the right result while without it doesnt.

A number of the other data member addresses used with "this" and without point correctly to the same address in memory.

In intf_entry_def::intf_entry_def(), the values are still viewable in their different parts, but still confusingly, to different areas.

(dbx) examine &ds_.last_sta_nam
0x021a2870: 0x00000000
(dbx) examine &this->ds_.last_sta_nam
0x021a2808: 0x015db798

Finally, once the objects have all been constructed and we're back in X::foo, the "this" reference finally yields the same address in memory, but unfortunately is pointing to the wrong one. The original last_sta_nam is consigned somewhere we cant get and the coredump occurs when last_sta_nam is attempted to be used (its invariants are broken).

(dbx) examine &entry_ptr_.ds_.last_sta_nam
0x021a2870: 0x00000000
(dbx) examine &this->entry_ptr_.ds_.last_sta_nam
0x021a2870: 0x00000000

I'm aware that the C++ standard leaves a number of things such as memory layout up to the implementation, but this doesnt seem like normal C++ behaviour to me.

Is there anyone out there knowledgeable enough in the sun C++ implementation with any ideas?

thx,
J