search for: assertingvh

While building test-suite with the new PM, I ran into problems with AssertingVH being triggered which is obvious in retrospect: https://llvm.org/bugs/show_bug.cgi?id=28400 Both cases I ran into revolve around LVI which holds AssertingVH. Essentially, what happens is this: 1. LVI holds an AssertingVH pointing at a BasicBlock 2. Some other pass ends up deleting that BB (e.g. S...

...no better suggestion. As the infrastructure matured, what I think is a substantially less horrible workaround is available in the form of what I implemented in r292773. Instead of just working around this for each analysis, this works around it in GlobalDCE for *any* function analysis stashing an AssertingVH. The down side is that it only defends against *function* removal and *function* analyses. =[ This may be a tiny bit better in some senses, but in others its worse, and frankly I think it is a pretty gross hack even in the best of cases. But let's take a look at some of the cases you identifie...

...suggestion. > > As the infrastructure matured, what I think is a substantially less horrible workaround is available in the form of what I implemented in r292773. Instead of just working around this for each analysis, this works around it in GlobalDCE for *any* function analysis stashing an AssertingVH. The down side is that it only defends against *function* removal and *function* analyses. =[ > > This may be a tiny bit better in some senses, but in others its worse, and frankly I think it is a pretty gross hack even in the best of cases. But let's take a look at some of the cases you...

On Mon, Jul 11, 2016 at 7:51 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Sean, > > Sean Silva wrote: > > While building test-suite with the new PM, I ran into problems with > > AssertingVH being triggered which is obvious in retrospect: > > https://llvm.org/bugs/show_bug.cgi?id=28400 > > > > Both cases I ran into revolve around LVI which holds AssertingVH. > > Essentially, what happens is this: > > > > 1. LVI holds an AssertingVH pointing at a Basi...

...M/LLVM/lib/VMCore/Value.cpp:561! The replaceAllUsesWith + eraseFromParent pattern remains correct, but there's more to the story than the parts we've focused on. This error means that there's some other code that is holding a pointer to the function you tried to delete, but is using AssertingVH to do so, so as to catch errors exactly like this producing a dangling pointer. The error message doesn't tell us who owns the AssertingVH (indeed, the asserting-vh doesn't know, much like a pointer doesn't know who owns it). So, under what circumstance are you doing this deletion?...

...can do to fix or further debug this problem? Thanks in advance, Peter Zion #0 0x965221a6 in szone_malloc_should_clear () #1 0x00916795 in ChromeMain () #2 0x96522148 in malloc_zone_malloc () #3 0x96520218 in malloc () #4 0x953da617 in operator new () #5 0x169f5872 in std::_Rb_tree<llvm::AssertingVH<llvm::BasicBlock>, std::pair<llvm::AssertingVH<llvm::BasicBlock> const, (anonymous namespace)::LVILatticeVal>, std::_Select1st<std::pair<llvm::AssertingVH<llvm::BasicBlock> const, (anonymous namespace)::LVILatticeVal> >, std::less<llvm::AssertingVH<llvm::Ba...

...lib/VMCore/Value.cpp:561! > > The replaceAllUsesWith + eraseFromParent pattern remains correct, but there's more to the story than the parts we've focused on. This error means that there's some other code that is holding a pointer to the function you tried to delete, but is using AssertingVH to do so, so as to catch errors exactly like this producing a dangling pointer. > > The error message doesn't tell us who owns the AssertingVH (indeed, the asserting-vh doesn't know, much like a pointer doesn't know who owns it). > > So, under what circumstance are you doi...

...2 lines are commented) that works. I compile the files with # llvm-as test_crash.ll -o - | llc -f -o temp.s - and get 0 llc 0x0000000000c6ab6f 1 llc 0x0000000000c6b38d 2 libpthread.so.0 0x00007feccd2270f0 3 llc 0x00000000009a270f llvm::DenseMap<llvm::AssertingVH<llvm::BasicBlock>, llvm::MMIAddrLabelMap::AddrLabelSymEntry, llvm::DenseMapInfo<llvm::AssertingVH<llvm::BasicBlock> >, llvm::DenseMapInfo<llvm::MMIAddrLabelMap::AddrLabelSymEntry> >::operator[](llvm::AssertingVH<llvm::BasicBlock> const&) + 31 4 llc...

Thanks, but I replaceAllUsesWith() - works well, but I still get bug in eraseFromParent(): While deleting: i32 (%class.B*, i32)* %_ZN1B1xEi An asserting value handle still pointed to this value! UNREACHABLE executed at /Users/neonomaly/LLVM/LLVM/lib/VMCore/Value.cpp:561! Yours sincerely, Kadysev Mikhail 21.04.2012, в 23:45, Nick Lewycky написал(а): > Михаил wrote: >> How correctly

...>> The replaceAllUsesWith + eraseFromParent pattern remains correct, but >> there's more to the story than the parts we've focused on. This error >> means that there's some other code that is holding a pointer to the >> function you tried to delete, but is using AssertingVH to do so, so as >> to catch errors exactly like this producing a dangling pointer. >> >> The error message doesn't tell us who owns the AssertingVH (indeed, >> the asserting-vh doesn't know, much like a pointer doesn't know who >> owns it). >> >&gt...

...eaking away from > standard assert. > > > Sorry to dig up this thread, but when re-reading it, I was surprised > that everyone seems to think this will be easily done across all of LLVM. It is almost done. It was far easier than the original patch. > > How can we support AssertingVH, which behaves as a POD-like struct > around a pointer in NDEBUG, and as a class with significant > (important) functionality to implement asserts on dangling value > handles in !NDEBUG builds? This was in the original patch. If you have a moment I recommend that you take a look, part...

Hi everyone, we have several header files in which the NDEBUG macro is being used. In some of these, the NDEBUG macro changes the size, the interface, or the layout of a type. One example is AssertingVH, which turns into a flat, transparent Value* wrapper in Release build. Now everywhere you use these headers, the state of the NDEBUG flag must be the same, or else bad things could happen. This turns out to be quite problematic for out-of-tree targets and projects, because it effectively forces th...

On Jan 3, 2014, at 2:19 PM, Chandler Carruth <chandlerc at google.com> wrote: >> While having different components of LLVM and consumers of LLVM able to intermix NDEBUG and !NDEBUG built code freely without ABI issues is nice-to-have in my book, the functionality provided by AssertingVH is significantly more nice-to-have, and I don't see any easy ways to contain or limit the exposure of this facility to library-level consumers. > > I hadn’t considered AssertVH, and I agree that losing it isn’t an option. > > Would it be possible to redesign AssertVH to be non-ABI...

On Nov 11, 2013, at 12:09 PM, Alp Toker <alp at nuanti.com> wrote: >> Even when you have a !NDEBUG build, the platform assert() is pretty >> crummy on Windows and generates, at best a UTF-16 dump, or sometimes >> just pops up a dialog. WebKit and other projects take the same approach >> and define their own assertion macros to deal with this portably. >>

...brary boundaries. We would want some pretty strong practical justification for breaking away from standard assert. > > Sorry to dig up this thread, but when re-reading it, I was surprised that everyone seems to think this will be easily done across all of LLVM. > > How can we support AssertingVH, which behaves as a POD-like struct around a pointer in NDEBUG, and as a class with significant (important) functionality to implement asserts on dangling value handles in !NDEBUG builds? > > While having different components of LLVM and consumers of LLVM able to intermix NDEBUG and !NDEBUG...

On Mon, Jul 11, 2016 at 11:17 PM, Sanjoy Das <sanjoy at playingwithpointers.com > wrote: > Hi Sean, > > Sean Silva wrote: > > > > But asan won't catch problems (insofar I understand how it works) if > > the free'ed BasicBlock is used as a key in a DenseMap or something -- > > if another BasicBlock gets allocated to the same location

...a69 in RemoveFromUseList (this=0x696a58) at /home/kharris/llvm30/llvm-3.0rc4.src/lib/VMCore/Value.cpp:493 #1 0x00007ffff54864d5 in ~ValueHandleBase (this=0x689648, first=<value optimized out>, last=...) at /home/kharris/llvm30/cl-install/include/llvm/Support/ValueHandle.h:74 #2 ~AssertingVH (this=0x689648, first=<value optimized out>, last=...) at /home/kharris/llvm30/cl-install/include/llvm/Support/ValueHandle.h:182 #3 _Destroy<llvm::AssertingVH<llvm::Instruction> > (this=0x689648, first=<value optimized out>, last=...) at /usr/include/c++/4.5/bit...

I can confirm that the issue has been caused by NDEBUG flag. On Mon, Jul 13, 2015 at 6:29 PM Reid Kleckner <rnk at google.com> wrote: > The layout of AssertingVH has depended on NDEBUG since 2009, which > predates any of our efforts to make LLVM's ABI resilient to mismatched > NDEBUG definitions between LLVM and its users. > > For now, make sure your definition of NDEBUG matches LLVM's. In the long > run, we could conceivably do somet...

...;mail at justinbogner.com> wrote: > Paweł Bylica <chfast at gmail.com> writes: > > I can confirm that the issue has been caused by NDEBUG flag. > > > > On Mon, Jul 13, 2015 at 6:29 PM Reid Kleckner <rnk at google.com> wrote: > > > > The layout of AssertingVH has depended on NDEBUG since 2009, which > > predates any of our efforts to make LLVM's ABI resilient to > mismatched > > NDEBUG definitions between LLVM and its users. > > > > For now, make sure your definition of NDEBUG matches LLVM's. In the > lo...

See http://llvm.org/bugs/show_bug.cgi?id=4406 The testcase at http://llvm.org/bugs/attachment.cgi?id=3141 needs to be updated to free the machine code with: ee->freeMachineCodeForFunction(cast<Function>(ll_main)); Once that's done, though, the AssertingVH is still triggered on destruction of the Module. It turns out that the stub for the external "write" is not registered by JITEmitter::AddStubToCurrentFunction() because DlsymStubs are not enabled. void JITEmitter::AddStubToCurrentFunction(void *StubAddr) { if (!TheJIT->areDlsymSt...