Problem with gcc4.7 and call_once

David Barto DBarto at visionpro.com
Wed Aug 7 12:54:31 PDT 2013


A MUCH simpler test:

#include <cstdio>
#include <pthread.h>
#include <mutex>

static std::once_flag init_hardware_to_use;

void
set_hw_to_use(void)
{
    printf("Just one time\n");
}

void
test()
{
    std::call_once(init_hardware_to_use, &set_hw_to_use);
}
void
test1()
{
    std::call_once(init_hardware_to_use, &set_hw_to_use);
}

void
test2()
{
    std::call_once(init_hardware_to_use, &set_hw_to_use);
}

int
main(int ac, char **av)
{
    test();
    test1();
    test2();
}

On Aug 7, 2013, at 8:44 AM, Jeremy Huddleston Sequoia <jeremyhu at apple.com> wrote:

> Can you provide a reproducible test case?
> 
> On Aug 7, 2013, at 7:32, David Barto <DBarto at visionpro.com> wrote:
> 
>> I've just run my monthly port update and I decided that it was time to use std::thread/std::future to execute things in the background.
>> 
>> The problem is that in std::future is a call to std::call_once and that call crashes my code:
>> 
>> (gdb) where
>> #0  0x0000000000000000 in ?? ()
>> #1  0x00007fff8f7e0ff0 in pthread_once ()
>> #2  0x0000000102a29440 in __gthread_once (__once=0x115d186a0, __func=0x112951b10 <__once_proxy>) at gthr-default.h:718
>> #3  0x0000000102a3283d in _ZSt9call_onceIMNSt13__future_base11_State_baseEFvRSt8functionIFSt10unique_ptrINS0_12_Result_baseENS4_8_DeleterEEvEERbEIKPS1_St17reference_wrapperIS8_ESF_IbEEEvRSt9once_flagOT_DpOT0_ (__once=@0x115d186a0, __f=@0x118146d10) at mutex:822
>> #4  0x0000000102a3118b in std::__future_base::_State_base::_M_set_result (this=0x115d18618, __res={<_Maybe_unary_or_binary_function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> >> = {<No data fields>}, <std::_Function_base> = {static _M_max_size = <optimized out>, static _M_max_align = <optimized out>, _M_functor = {_M_unused = {_M_object = 0x114383670, _M_const_object = 0x114383670, _M_function_pointer = 0x114383670, _M_member_pointer = {__pfn = 0x114383670, __delta = 4631664872}}, _M_pod_data = "p68\024\001\000\000\000?\021\024\001\000\000"}, _M_manager = 0x102a3cfea <std::_Function_base::_Base_manager<std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<int>, std::__future_base::_Result_base::_Deleter>, int> >::_M_manager(std::_Any_data&, std::_Any_data const&, std::_Manager_operation)>}, _M_invoker = 0x102a3cf97 <std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()(), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<int>, std::__future_base::_Result_base::_Deleter>, int> >::_M_invoke(std::_Any_data const&)>}, __ignore_failure=false) at future:359
>> #5  0x0000000102a38762 in std::__future_base::_Task_state<int ()()>::_M_run (this=0x115d18618) at future:1268
>> #6  0x0000000102a35548 in std::packaged_task<int ()()>::operator() (this=0x115d180d8) at future:1376
>> 
>> So I upgraded to gcc48 and noticed that the library libstdc++.dylib didn't change or update. In fact it linked to the same library being used by gcc47 in /opt/local/lib:
>> 512_  ls -l /opt/local/lib/libstdc++.6.dylib 
>> 6344 -rwxr-xr-x  1 root  admin  3245696 Jul  1 10:14 /opt/local/lib/libstdc++.6.dylib
>> 
>> Anyone else having problems with std::call_once?
>> 
>> Any workaround that can be suggested?
>> 
>> David
>> 
>> _______________________________________________
>> macports-users mailing list
>> macports-users at lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/macports-users
> 



More information about the macports-users mailing list