Problem with num_put on zOS

[Nicole Willson <wi...@roguewave.com>]

Martin,
I'm trying to debug an issue with num_put where it fails an ASSERT in
building a custom locale.  We are using numpunct as the facet type.  I'm
having trouble determining exactly where it is going wrong.  

I've traced it to when it comes out of include/loc/_locale.h: inline const
__rw_facet*
__rw_get_facet (const _STD::locale &__loc, const _STD::numpunct<char>*)

Inside this function the facet._C_pid is 8 (well pointing to it)
Back in 
template <class _Facet>
inline locale::locale (const locale &__rhs, _Facet *__facet) : _C_body(0)

after 
if (_RW::__rw_get_facet (__rhs, (_Facet*)0) == __facet)
__facet._C_pid is now nicely populated in a working system, but has reverted
to 0 on the zOS system.  I don't see where __facet is even messed with in
this if statement.  Just magically has the right _C_pid after the
__rw_get_facet.  And just as magically has the wrong _C_pid (0) after the
__rw_get_facet on the zOS system.

Any ideas where I should be looking?  Why does this if statement set the
_C_pid for __facet on a working system?  Or more appropriately, I should
ask, How?

Thanks

Nicole Willson
Consulting Engineer
Rogue Wave Software, Inc.
A Division of Quovadx
303-545-3210

Re: Problem with num_put on zOS

[Martin Sebor <se...@roguewave.com>]

Nicole Willson wrote:
> Martin,
> I'm trying to debug an issue with num_put where it fails an ASSERT in
> building a custom locale.  We are using numpunct as the facet type.  I'm
> having trouble determining exactly where it is going wrong.  
> 
> I've traced it to when it comes out of include/loc/_locale.h: inline
> const __rw_facet*
> __rw_get_facet (const _STD::locale &__loc, const _STD::numpunct<char>*)
> 
> Inside this function the facet._C_pid is 8 (well pointing to it)
> Back in 
> template <class _Facet>
> inline locale::locale (const locale &__rhs, _Facet *__facet) :
> _C_body(0)
> 
> after 
> if (_RW::__rw_get_facet (__rhs, (_Facet*)0) == __facet)
> __facet._C_pid is now nicely populated in a working system, but has
> reverted to 0 on the zOS system.  I don't see where __facet is even
> messed with in this if statement.  Just magically has the right _C_pid
> after the __rw_get_facet.  And just as magically has the wrong _C_pid
> (0) after the __rw_get_facet on the zOS system.
> 
> Any ideas where I should be looking?  Why does this if statement set the
> _C_pid for __facet on a working system?  Or more appropriately, I should
> ask, How?

This looks like a case of ODR violation (I mentioned this to Keith
earlier today). I suspect that the library is not configured properly
in that it may not have detected that the compiler/linker do not
collapse static data members of class templates (etc.) across object
file (or library) boundaries. Grep your config header for the string
_COLLAPSE_. You should get no hits or, if you do come up with some,
the macros with the string in them will not be #defined. If that is
teh case, compile and link the corresponding config tests to see what
the real behavior is (this involves building a library in the process,
something stdcxx can do but RCB can't).

Alternatively, try #defining all of these macros and recompiling the
library and the test to quickly see if it solves the problem. If it
does, you can just hardcode them for this platform. (This is not as
safe as actually compiling the tests but it would be a quick way to
see if my theory holds water).

Martin