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 <[email protected]>
wrote:
> Can you provide a reproducible test case?
>
> On Aug 7, 2013, at 7:32, David Barto <[email protected]> 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::__futur
e_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
>> [email protected]
>> https://lists.macosforge.org/mailman/listinfo/macports-users
>
_______________________________________________
macports-users mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-users
