Boost C++ Libraries: Ticket #4260: core dump restoring simple archive on 64-bit Solaris

attachment set

crispin.boylan@… — Wed, 26 May 2010 14:45:46 GMT

attachment → stream.cpp

Simple test

anonymous — Wed, 26 May 2010 14:50:22 GMT

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)

cc set

cris@… — Wed, 26 May 2010 15:00:44 GMT

cc cris@… added

attachment set

crispin.boylan@… — Wed, 26 May 2010 16:50:09 GMT

attachment → 64_serial_fails.txt.gz

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

crispin.boylan@… — Wed, 26 May 2010 16:50:50 GMT

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

Robert Ramey — Mon, 28 Jun 2010 16:26:18 GMT

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

attachment set

crispin.boylan@… — Thu, 01 Jul 2010 13:06:53 GMT

attachment → stream_cpp_debug.txt

output of debug session for stream.cpp

crispin.boylan@… — Thu, 01 Jul 2010 13:09:27 GMT

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 — Thu, 01 Jul 2010 15:46:37 GMT

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@… — Thu, 01 Jul 2010 16:18:28 GMT

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 — Thu, 01 Jul 2010 16:23:33 GMT

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

Do these tests pass?

Robert Ramey

crispin.boylan@… — Thu, 01 Jul 2010 16:48:56 GMT

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

crispin.boylan@… — Tue, 13 Jul 2010 09:47:02 GMT

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@… — Tue, 13 Jul 2010 12:25:22 GMT

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

status changed; resolution set

Robert Ramey — Wed, 04 Aug 2010 19:14:18 GMT

status new → closed
resolution → wontfix

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@… — Thu, 06 Jan 2011 15:30:20 GMT

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