[asio] order of initialization problem with boost::asio::error::system_category

I am getting failures of the error.cpp regression test for asio that seem to be related to an order of initialization problem with the new boost::asio::error::system_category. It appears that asio::error::system_category is a const reference initialized by error::detail::get_system_category(), which simply returns boost::system::system_category. The problem seems to be that boost::system::system_category is itself a const reference to the actual system_category_const object created in Boost.System's error_code.cpp file. If it happens that the boost::asio::error::system_category reference is initialized before the boost::system::system_category reference, then boost::asio::error::system_category is a copy of the uninitialized boost::system::system_category reference rather than a reference to the system_category_const object. Attempting to use the category-related functions of an error_code created from the asio system_category enums then triggers an access violation. Of course, if boost::system::system_category is initialized first, then everything is fine. Hopefully that all made sense. Thanks, -Dave

Hi David I just ran into this issue and it had been driving me nuts because the access violation only occured when compiled w/o optimizations mode (-O0 gcc 4.1.1) but WITH optimizations turned on, it magically works. The code that triggers the seg fault is line 391 of boost/system/error_code.hpp (operator<<): os << ec.category().name() << ':' << ec.value(); I get the same behavior using .message() as well. It seems that, in debug mode, m_cat in the error_code has an address of 0x0 (well, the virtual pointer does). In release mode it has a valid address. Does this sound like it could be the order-of-init issue you are facing? Do you happen to have a solution? I'm not sure how to force order-of-initialization (or if the std even allows it). Cheers, Chris On 9/15/07, David Deakins <ddeakins@veeco.com> wrote:
I am getting failures of the error.cpp regression test for asio that seem to be related to an order of initialization problem with the new boost::asio::error::system_category. It appears that asio::error::system_category is a const reference initialized by error::detail::get_system_category(), which simply returns boost::system::system_category. The problem seems to be that boost::system::system_category is itself a const reference to the actual system_category_const object created in Boost.System's error_code.cpp file. If it happens that the boost::asio::error::system_category reference is initialized before the boost::system::system_category reference, then boost::asio::error::system_category is a copy of the uninitialized boost::system::system_category reference rather than a reference to the system_category_const object. Attempting to use the category-related functions of an error_code created from the asio system_category enums then triggers an access violation. Of course, if boost::system::system_category is initialized first, then everything is fine. Hopefully that all made sense.
Thanks, -Dave
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Chris Fairles wrote:
Hi David
I just ran into this issue and it had been driving me nuts because the access violation only occured when compiled w/o optimizations mode (-O0 gcc 4.1.1) but WITH optimizations turned on, it magically works.
The code that triggers the seg fault is line 391 of boost/system/error_code.hpp (operator<<): os << ec.category().name() << ':' << ec.value();
I get the same behavior using .message() as well.
It seems that, in debug mode, m_cat in the error_code has an address of 0x0 (well, the virtual pointer does). In release mode it has a valid address.
Does this sound like it could be the order-of-init issue you are facing? Do you happen to have a solution? I'm not sure how to force order-of-initialization (or if the std even allows it).
Chris, are you using code from the Subversion trunk? That problem is supposed to have been fixed some time ago. --Beman
participants (3)
-
Beman Dawes
-
Chris Fairles
-
David Deakins