From: Chris Fairles (chris.fairles_at_[hidden])
Date: 2007-10-13 18:23:02
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
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
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).
On 9/15/07, David Deakins <ddeakins_at_[hidden]> 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.
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost