Opened 10 years ago

Closed 10 years ago

#7553 closed Bugs (invalid)

interprocess/asio interference issue

Reported by: Todd Chadwick <ctchadwick@…> Owned by: Ion Gaztañaga
Milestone: To Be Determined Component: interprocess
Version: Boost 1.51.0 Severity: Not Applicable
Keywords: ipc, asio, exception Cc:

Description

I am experiencing an issue where trying to access a previously created shared memory segment causes the following exception to be thrown when using the IPC and ASIO (TCP sockets specifically) libraries together:

terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >'

what(): resolve: No such host is known

This is issue does not occur when I utilize 1.49 libraries. When the shared memory is removed the application does not throw this exception but when subsequently restarted, the exception is thrown. My goal for utilizing the shared memory structure is that it provide a persistence mechanism for a collection of IDs generated by the application that need to be available should a crash happen. Accessing the shared memory at different application instances without creating the socket works as expected (the previously created shared segment is accessible). The exception happens whenever the shared memory segment exists prior to the application start up. Again this does not happen with the verion 1.49 libraries.

Attachments (1)

test-asio.cpp (8.1 KB ) - added by Todd Chadwick <ctchadwick@…> 10 years ago.

Download all attachments as: .zip

Change History (4)

by Todd Chadwick <ctchadwick@…>, 10 years ago

Attachment: test-asio.cpp added

comment:1 by Todd Chadwick <ctchadwick@…>, 10 years ago

I have attached a file that replicates the problem on my setup. I am building on a Win7-64 machine, using MinGW 4.6.2 (32bit). I'm employing static linking to the libraries.

comment:2 by Todd Chadwick <ctchadwick@…>, 10 years ago

Severity: ProblemNot Applicable

I have managed to resolve the issue. The problem resided in another piece of code, although I was able to replicate a similar issue with the code I posted, albeit not the same issue. As of my current experiment, I'd say my issue is resolved and appears to be my implementation of the libraries and not something in the libraries.

comment:3 by viboes, 10 years ago

Resolution: invalid
Status: newclosed
Note: See TracTickets for help on using tickets.