search for: call_once

...11:18, Dmitry Vyukov via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> On Thu, Sep 1, 2016 at 2:30 PM, Kuba Brecka <kuba.brecka at gmail.com> wrote: >>>> Hi, >>>> >>>> I'm trying to write a TSan interceptor for the C++11 call_once function. There are currently false positive reports, because the inner __call_once function is located in the (non-instrumented) libcxx library, and on macOS we can't expect the users to build their own instrumented libcxx. >>>> >>>> TSan already supports pthread_once...

> On 2 Sep 2016, at 11:18, Dmitry Vyukov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, Sep 1, 2016 at 2:30 PM, Kuba Brecka <kuba.brecka at gmail.com> wrote: >> Hi, >> >> I'm trying to write a TSan interceptor for the C++11 call_once function. There are currently false positive reports, because the inner __call_once function is located in the (non-instrumented) libcxx library, and on macOS we can't expect the users to build their own instrumented libcxx. >> >> TSan already supports pthread_once and dispatch_on...

Hi, I'm trying to write a TSan interceptor for the C++11 call_once function. There are currently false positive reports, because the inner __call_once function is located in the (non-instrumented) libcxx library, and on macOS we can't expect the users to build their own instrumented libcxx. TSan already supports pthread_once and dispatch_once by having inter...

Same problem exists, thread A can still be within REAL(call_once), but after it ran user code and set the flag to ~0. Roughly, call_once does: __call_once(flag, arg, func) { mutex_lock(mut); if (flag == BEING_INITIALIZED) { wait } else if (flag == NOT_INITIALIZED_AT_ALL) { flag = BEING_INITIALIZED; mutex_unlock(mut); func(arg); // <===...

Hi all, I observe that r220932 (Removing the static initializer in ManagedStatic.cpp by using llvm_call_once to initialize the ManagedStatic mutex.) is causing tablegen to segfault in PPC platforms during static initialization. The crash happens while calling std::call_once introduced by this patch in the wrapper used in getManagedStaticMutex. I understand this call is buggy for some platforms (or proba...

Adding Jiangning Liu to the thread. Jiangning reported a similar issue on the llvm-commits list on Debian aarch64. In general it sounds like std::call_once may not really be bug free. Jiangning, can you please provide your gcc/libstdc++ version? Thanks, -Chris > On Nov 4, 2014, at 9:38 AM, Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote: > > On Tue, 2014-11-04 at 12:17 -0500, Samuel F Antao wrote: >> Ok, I'll put a pa...

...chmidt <wschmidt at linux.vnet.ibm.com> > To: Samuel F Antao/Watson/IBM at IBMUS > Cc: azanella at linux.vnet.ibm.com, beanz at apple.com, Hal Finkel > <hfinkel at anl.gov>, LLVM Dev <llvmdev at cs.uiuc.edu> > Date: 11/04/2014 12:11 PM > Subject: Re: Issue with std::call_once in PPC64 platform > > On Tue, 2014-11-04 at 11:59 -0500, Samuel F Antao wrote: > > Hi Bill, > > > > You can find the same issue in the buildbot: > > > > http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/ > 16444/steps/compile.llvm.stage2/logs/std...

...> -Jiangning > > 2014-11-05 4:46 GMT+08:00 Chris Bieneman <beanz at apple.com>: > >> Adding Jiangning Liu to the thread. >> >> Jiangning reported a similar issue on the llvm-commits list on Debian >> aarch64. >> >> In general it sounds like std::call_once may not really be bug free. >> >> Jiangning, can you please provide your gcc/libstdc++ version? >> >> Thanks, >> -Chris >> >> >> > On Nov 4, 2014, at 9:38 AM, Bill Schmidt <wschmidt at linux.vnet.ibm.com> >> wrote: >> > >&gt...

...chmidt <wschmidt at linux.vnet.ibm.com> > To: Samuel F Antao/Watson/IBM at IBMUS > Cc: LLVM Dev <llvmdev at cs.uiuc.edu>, beanz at apple.com, Hal Finkel > <hfinkel at anl.gov>, azanella at linux.vnet.ibm.com > Date: 11/04/2014 11:45 AM > Subject: Re: Issue with std::call_once in PPC64 platform > > Hi Samuel, > > I haven't encountered this problem. What gcc/libstdc++ are you using? > BE or LE? > > Copying Adhemerval in case he has heard of any related issues. > > Thanks, > Bill > > On Mon, 2014-11-03 at 20:19 -0500, Samuel F Antao...

..._emutls_v._ZSt15__once_callable, >> __emutls_v._ZSt11__once_call ] >> >> Those seem to correspond to std::__once_callable and std::__once_call, >> which are indeed present in the C++ standard library. And I imagine >> they are needed because the DSO makes calls to std::call_once(). But >> ORC seems to be looking for them with the prefix "__emutls_v". >> >> I had a similar problem in the past, which I thought Lang had fixed... >> See this thread: >> >> http://lists.llvm.org/pipermail/llvm-dev/2020-January/138402.html >> &g...

...; On Fri, Jun 20, 2014 at 10:33 AM, Yaron Keren <yaron.keren at gmail.com> >> wrote: >> >>> The whole "mutex" and "shared_mutex" files are #ifdef >>> _GLIBCXX_HAS_GTHREADS so if no _GLIBCXX_HAS_GTHREADS there are no mutexes >>> and no call_once. thread lives in "thread" which is also #ifdef >>> _GLIBCXX_HAS_GTHREADS. >>> "condition_variable" and "future" are the same. >>> >>> I have tested gcc 4.8.2 predefines and _GLIBCXX_HAS_GTHREADS isn't >>> there nor it is...

...utex from C++11. This is really unfortunate, because we were hoping that moving to C++11 would allow us to use standard, portable threading primitives. Does this version of MinGW have any C++11 threading support? Is it just recursive_mutex that is missing, or do we have to avoid std::mutex, std::call_once, etc? lld has been using all of these things for some time now, and in theory we have the same baseline toolchain requirements. If it's just std::recursive_mutex, how long do you think it would take to implement that for mingw's libstdc++? Do you have a sense of which version of mingw is...

...owing error message: Symbols not found: [ __emutls_v._ZSt15__once_callable, __emutls_v._ZSt11__once_call ] Those seem to correspond to std::__once_callable and std::__once_call, which are indeed present in the C++ standard library. And I imagine they are needed because the DSO makes calls to std::call_once(). But ORC seems to be looking for them with the prefix "__emutls_v". I had a similar problem in the past, which I thought Lang had fixed... See this thread: http://lists.llvm.org/pipermail/llvm-dev/2020-January/138402.html Perhaps it wasn't as fixed as I thought? Or maybe there is...

...o 2? I don't really like it either. On Fri, Jun 20, 2014 at 10:33 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > The whole "mutex" and "shared_mutex" files are #ifdef > _GLIBCXX_HAS_GTHREADS so if no _GLIBCXX_HAS_GTHREADS there are no mutexes > and no call_once. thread lives in "thread" which is also #ifdef > _GLIBCXX_HAS_GTHREADS. > "condition_variable" and "future" are the same. > > I have tested gcc 4.8.2 predefines and _GLIBCXX_HAS_GTHREADS isn't there > nor it is defined anywhere with the win32 version...

...but not to read the return value, so the // return value is not thread safe. Can we tell TSAN to ignore the statistics somehow? Alternatively, is there a fix someone can suggest? 2) Pass initialization. This macro does not please TSAN (even though it seems written with TSAN in mind): #define CALL_ONCE_INITIALIZATION(function) \ static volatile sys::cas_flag initialized = 0; \ sys::cas_flag old_val = sys::CompareAndSwap(&initialized, 1, 0); \ if (old_val == 0) { \ function(Registry); \ sys::MemoryFence(); \ TsanIgnoreWritesBegin(); \ TsanHappensBefore(&initialized);...

...x, as it doesn't seem like anyone is using it in a multi-threaded fashion, but I could be wrong about that, so I'll wait for more information. Eventually the goal would be to actually enforce once-only inside of ManagedStatic (I found this bug actually by changing ManagedStatic to sue std::call_once), so we could prevent problems like this from ever happening in the future. On Mon, Jun 2, 2014 at 9:53 AM, David Blaikie <dblaikie at gmail.com> wrote: > On Mon, Jun 2, 2014 at 9:39 AM, Zachary Turner <zturner at google.com> wrote: > > I actually had an idea about how to...

+llvmdev. I find this pretty surprising. Actually, we already use std::mutex and std::recursive_mutex in clang, lld, and other llvm projects, it's just a coincidence that it hadn't been introduced into LLVM until my commits. I'm not sure what the right thing to do here is. If I understand correctly, it seems like in order to encounter this, a) you must be using GCC, b) you must be

I actually had an idea about how to fix this in a relatively painless manner. Although given my experience over the past 4 days, it might not be best to call it painless without first trying :) The idea is to make a StaticPassRegistry. RegisterPass<> only touches the StaticPassRegistry, and nothing else touches the StaticPassRegistry. So once you enter main(), StaticPassRegistry can be

...2 hangs with the splash screen 38586 Green Ranch crashes when opening 38602 Steam 'steamwebhelper.exe' (CEF) crashes on unimplemented function ADVAPI32.dll.ImpersonateAnonymousToken during clipboard paste into 'search store' field 38607 GOG Galaxy client needs msvcp110.dll._Call_onceEx 38628 League of Legends : LoLPatcherUx.exe crash 38643 Sigil Portable 0.8.6 crashes on unimplemented function msvcr120.dll._dsign ---------------------------------------------------------------- Changes since 1.7.43: Alex Henrie (7): winmm: Improve grammar by changing "or&quot...