SEO

Thanks for reading.

I am getting cores because a std::string allocated in one module, and
then returned to another module by a method call, is apparently not
compatible with the std::string used by the other module. The first
module, which news the string, can manipulate it fine. It returns the
pointer on a call. The second module gets bad values for c_str() and
len(). It is apparently expecting a different size or alignement of
the member data (e.g. _Ptr, _Len). I can see this by looking at the
string objects data in xldb and comparing it to the data in objects
created by the second module (which it can use fine). The values
returned by c_str() and len() also corespond with the offset shift. In
the first module the _Ptr is at offset 1 (i.e. the first member,
"_String_val...", took up one 1 byte). In the second _Ptr is at
offset 4.

What could be causing this?

I tried explicitly using std::string in both modules.

I suspect some static or dynamic link thing.
I have some older builds of the program, with essentially the same
code, that don't have this problem.


I'm desperate and open to any suggestions.

Thanks,
Micheal

m_p_v_13@yahoo.com (m v) writes:

> What could be causing this?

Different versions of the compiler, or different compilers, or
different "pack" flags during the compilation of the 2 modules,
or using different STL implementations (e.g. one using the xlC
implementation, the other STLport).

Did you compile both modules yourself?
On the same machine? With the same flags?

> I suspect some static or dynamic link thing.

The data layout in std::string (or any other class) should not be
affected by linking.

> I have some older builds of the program, with essentially the same
> code, that don't have this problem.

Perhaps you've upgraded the compiler but rebuilt only parts of
the program?

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

Paul,
Thanks.
See my responses below.

Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> wrote in message news:<m3ad0nhrhc.fsf@salmon.parasoft.com>...
> m_p_v_13@yahoo.com (m v) writes:
>
> > What could be causing this?
>
> Different versions of the compiler, or different compilers, or
> different "pack" flags during the compilation of the 2 modules,
> or using different STL implementations (e.g. one using the xlC
> implementation, the other STLport).

The two modules are compiled one after the other from the same
makefile. They use the same compiler (VAC++ 5.0.2) and same compile
options. They are in the same directory and are archived into a
library and later linked with other application modules and sytem
libraries.


I am now looking through the include files included by these modules
to see if one of those changed the packing outside of it's scope. I'm
skeptical of how this could affect the internal structure of the
string class since I am assuming, ignorantly, that I am not compileing
the string class implementation but just linking it in.

Bye the way, besides the data being aligned differantly in strings
created by the two different modules, a sizeof( a string object ) gets
16 in one module and 13 in the other.




>
> Did you compile both modules yourself?
> On the same machine? With the same flags?

Yes.

>
> > I suspect some static or dynamic link thing.
>
> The data layout in std::string (or any other class) should not be
> affected by linking.
>
> > I have some older builds of the program, with essentially the same
> > code, that don't have this problem.
>
> Perhaps you've upgraded the compiler but rebuilt only parts of
> the program?

Some application libraries that are linked in, were build with the
older IBM C++ compiler, I think, but the two that are exchanging a
string were built the same.


>
> Cheers,

m_p_v_13@yahoo.com (m v) writes:

> I am now looking through the include files included by these modules
> to see if one of those changed the packing outside of it's scope. I'm
> skeptical of how this could affect the internal structure of the
> string class since I am assuming, ignorantly, that I am not compileing
> the string class implementation but just linking it in.

Your assumption is incorrect: preprocess any file that #includes string,
and you'll see this:

#line 39 "/usr/vacpp/include/xstring"
namespace std {
...
template<class _E,
class _Tr = char_traits<_E>,
class _Ax = allocator<_E> >
class basic_string : public _String_val<_E, _Ax> {
...
typedef basic_string<char, char_traits<char>, allocator<char> >
string;

You *are* compiling (template) string implementation in each and
every source that uses std::string.

> Bye the way, besides the data being aligned differantly in strings
> created by the two different modules, a sizeof( a string object ) gets
> 16 in one module and 13 in the other.

The basic_string above has just 3 data members:

_E *_Ptr; size_type _Len, _Res;

and inherits _Alval (of type 'allocator<char>::rebind<char>:ther')
from _String_val (this class is empty). This gives std::string a
"natural" size of 12 or 16 (in 32-bit mode), depending on whether
the empty class takes up 0 or 1 byte(s).

In my tests, sizeof(std::string) is 16.

With '#pragma pack(1)' in effect, it is not entirely unreasonable to
expect sizeof(std::string) to become 13.

Try moving the '#include <string>' to the beginning of the "bad"
source, and see if the resulting sizeof() changes.

I bet it does, in which case some other header of yours likely has
unbalanced '#pragma pack(1)'

Good luck.
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

Paul,


>
> I bet it does, in which case some other header of yours likely has
> unbalanced '#pragma pack(1)'
>

Paul,

Thanks a lot!

That was it.
There was an open #pragma options align=packed
in an .h file that was included indirectly with some recent changes.
It needed to be closed with #pragma options align=reset.

So, anyone, if you ever get a bad pointer or garbage from
string::c_str() or
a bad value from string::length() on a std::string that was created in
another compile module, check for packing / align mismatches. I guess
this goes for most
template implemented classes. Be very careful with pack pragma.

Regards,
Michael