core dump restoring simple archive on 64-bit Solaris

[crispin.boylan@…]

When restoring a simple archive with 4 integers, I get a core dump when restoring the 4th. The first two are retrieved fine, the 3rd one is not restored and makes the stream go bad, and the 4th crashes it with a StreamError exception.

This only happens if I configure the libraries with address-model=64. This is with Sunstudio 12 Update 1 with all recent patches applied.

In 32-bit mode the test runs through to completion.

[crispin.boylan@…]

Simple test

[anonymous]

output from running the test:

1 2 3 22 serialization::archive 5 1 2 3 4

27 22 Val: 1 29 22 Val: 2 31 22 Val: 2 -1 22 BAD Abort(coredump)

[crispin.boylan@…]

output from bjam toolset=sun address-model=64 in libs/serialization

[crispin.boylan@…]

a lot of serialization tests failed with address-model=64 so i've attached the output of the failed tests.

[Robert Ramey]

I've looked at your test and it shows the problem but doesn't help me fix it.

Can you trace down into stlport and see what is really going wrong?

Robert Ramey

[crispin.boylan@…]

output of debug session for stream.cpp

[crispin.boylan@…]

i cant see whats going wrong at all - from what I can see its getting to the stream in the right place, its calling the correct load<int> method, then loading that from the stream (which is in the right position and good() before loading), which just comes back with bad() set on the stream.

i cant seem to step into the actual stream code in stlport.

[Robert Ramey]

which version of stlport are you using?

Are there any independent tests of that version of stlport?

Looking at the test matrix - there are a number of 64 bit platforms passing w/o problems. Also a number of stlport tests. BUT, yours is the only test which combines 64 platform with stlport. It would be interesting to write a small test which verifies the correct functioning of the stlport 64 bit version independently of the serialization library. Perhaps stlport itself includes some tests that you can run.

Robert Ramey

[crispin.boylan@…]

this is just the internal version of stlport4 (4.5.3) which is shipped with sunstudio 12.1

I would assume that version has been tested with boost? It's the same version (Sun C++ 5.10) which is listed on the release notes,and there's no way to build boost with the crusty old Cstd which is the default. but like you say maybe it just hasnt been tested in 64-bit mode.

[Robert Ramey]

take a look at ​http://www.stlport.com/doc/testsuite.html

Do these tests pass?

Robert Ramey

[crispin.boylan@…]

pretty much everything passes, but there are no iostreams tests in there unfortunately.

[crispin.boylan@…]

i seem to have made some progress:

if I comment out lines 129-137 in ./boost/archive/impl/basic_text_iprimitive.ipp and rebuild the library my test runs through to completion.

the lines are:

129  //    if(! no_codecvt){
130  //        archive_locale.reset(
131  //            add_facet(
132  //                std::locale::classic(),
133  //                new codecvt_null<BOOST_DEDUCED_TYPENAME IStream::char_type>
134  //            )
135  //        );
136  //        is.imbue(* archive_locale);
137  //    }

[crispin.boylan@…]

it seems to be the addition of a codecvt facet to the locale, if I use:

new std::locale(std::locale::classic())

as the locale then the test also completes successfully.

it doesnt seem to be the codecvt_null facet in itself, as if I use:

new std::locale(std::locale::classic(), new std::codecvt<char,char,mbstate_t>)

I also get the same crash

[Robert Ramey]

I have no idea what to do with this.

I could suggest that one use no_codecvt when opening the archive. This wouldn't be a fix - just a workaround for this compiler/stlport lib.

So I'm going to close this with "can't fix"

Robert Ramey

[crispin.boylan@…]

i've finally tracked it down to a general fault in the stlport implementation in Solaris Studio.

A bug has now been raised with Oracle:

​http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7010483