A MUCH simpler test:
#include
#include
#include
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
Did it work when you were using libstdcxx-4.7?
__once_proxy is just looking up some other function (__once_call) using
__emutls_get_address and executing it (makes sense based on the name).
__emutls_get_address is returning 3 in this instance, so something looks wrong
with emutls:
(lldb) disa
Same here with gcc-4.7 and gcc-4.8
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x
[Switching to process 10581 thread 0x1203]
0x0001000c6b20 in __once_proxy ()
___
Same results with gcc 4.8 +universal
649_ rm threading ; make threading
/opt/local/bin/g++-mp-4.8 -std=c++11 -g threading.cpp -o threading
650_ ./threading
Segmentation fault: 11
Though I have not made any changes to libstdc++, just updated to the last
version from the port on Monday.
D
On Aug 7, 2013, at 8:44 AM, Jeremy Huddleston Sequoia
wrote:
> Can you provide a reproducible test case?
>
Compile line is:
/opt/local/bin/g++-mp-4.7 -std=c++11 -g threading.cpp -o threading
The following is the result of the execution of the code.
Program received signal EXC_BAD_ACCESS, C
On Aug 7, 2013, at 09:32, David Barto wrote:
> 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
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 0x in ?? ()
#1 0x7fff8f7e0ff
