boost::interprocess::basic_string::c_str() result not null-terminated when used with shared memory allocator

[Anil Gangolli <anil@…>]

I'm seeing this issue using boost::interprocess:basic_string (aliases boost::container::string) allocated using boost::interprocess::allocator based on a boost::interprocess::managed_map_file::segment_manager.

The c_str() function is not returning a null-terminated string in general. This problem does not seem to occur using boost::container::string (using the standard allocator).

The attached test program illustrates the problem. I compiled the test under gcc 4.5 using flags -DBOOST_DATE_TIME_NO_LIB

[Anil Gangolli <anil@…>]

test program for ticket 5593

[Anil Gangolli <anil@…>]

It now appears the problem is platform-specific.

I retested on Linux (specifically Ubuntu 10.04.2) with gcc 4.4.3. I do not see the reported problem there.

I am seeing the issue on Mac OS 10.6.7. The gcc is 4.5.3 from Mac Ports. Dynamic dependencies are:

/opt/local/lib/gcc45/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.14.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 103.0.0) /opt/local/lib/gcc45/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.10)

I haven't yet tested on Linux with gcc 4.5.x

[anonymous]

I just tested on Linux (Ubuntu 10.04.2) with g++ 4.5.3 and did not see the problem there.

So I am only able to reproduce the problem on Mac OS. Version details in my previous comment.

The underlying cause may be a bug in one of the MacOS/MacPorts libraries or it may be due to an incorrect expectation in the Boost code that is not met on Mac OS.

The reason that I suspect a Boost Interprocess issue is that even on the Mac platform, one sees no problem using the standard allocator, only the shared memory one.

[anonymous]

(anil@…):

I tested on MacOS 10.6.7 with the gcc 4.2.1 that comes with XCode and everything was fine. As a result I am retracting the bug.

[dominik.ernst@…]

I just found this Bug-report, when I searched for information about strange behaviour. Following Code

cout << model.c_str() << "  ";
cout << model << std::endl;

results in

BS-2020Sj B�GmA BS-2020S

(the original string is BS-2020S, model is a basic_string) which looks like a missing null-termination.

Linux Mint 13, gcc 4.6, boost 1.47